数据库连接串应拆解为原子变量（如DB_HOST、DB_PORT等）并通过分层变量注入管理：默认用项目根目录.env文件，生产环境用--env-file指定.env.prod覆盖，服务级可用env_file隔离配置，严禁在.env中硬编码完整DATABASE_URL以防特殊字符解析错误、协议不灵活及变量不可复用。
数据库连接串是多环境切换中最敏感也最易变的配置项，docker compose 本身不直接“管理”它，而是通过分层变量注入机制实现安全、灵活的替换。关键在于把连接串拆解为可复用的组件（如 host、port、user、password、dbname），再按环境分别赋值，避免硬编码或拼接错误。
用 .env 文件定义基础变量
在项目根目录放一个 .env 文件，作为默认值来源（开发环境常用）：
- DB_HOST=localhost
- DB_PORT=5432
- DB_USER=devuser
- DB_PASSWORD=devpass
- DB_NAME=myapp
然后在 docker-compose.yml 中引用：
environment:
- DATABASE_URL=postgres://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}Compose 启动时自动读取 .env 并完成变量插值，无需额外参数。
用 --env-file 指定不同环境的变量文件
为生产环境单独准备 .env.prod：
- DB_HOST=db-prod.internal
- DB_PORT=5433
- DB_USER=produser
- DB_PASSWORD=very-secure-token
- DB_NAME=myapp_prod
启动时显式指定：
docker compose --env-file .env.prod up -d
此时 .env.prod 的值会覆盖 .env 中同名变量，且优先级高于 shell 环境变量（除非你手动 export 过）。
在服务中用 env_file 加载更细粒度配置
如果某些服务需要隔离数据库配置（比如只给 app 服务传 DB 变量，不给 nginx），可在 service 级别用 env_file：
services:
app:
image: myapp:latest
env_file:
- .env.db # 仅含 DB_* 变量的专用文件
environment:
- APP_ENV=production这种写法适合混合部署场景：多个服务共享同一份 .env.db，但各自有独立的运行时变量。
避免连接串拼接陷阱
不要在 .env 文件里直接写完整 DATABASE_URL，原因有三：
- 密码中若含特殊字符（如
@、/、:）会导致 URL 解析失败 - 不同环境可能用不同协议（postgres:// vs mysql://），硬编码失去灵活性
- 无法复用单个变量（例如测试脚本可能只需 DB_HOST）
推荐始终拆解为原子变量，让应用自己组装——或者由镜像内的 entrypoint 脚本处理，而不是依赖 Compose 插值。
