Docker Compose 环境变量和密钥怎么管理？替换、注入与访问范围
先区分三种配置流向
本文适用于当前 Docker Compose 插件的本地部署。项目里的 .env 常用于替换 Compose 文件中的变量；服务的 environment 和 env_file 用于设置容器环境；secrets 则把授权给服务的敏感内容以文件形式提供。这三者用途不同，不能因为变量出现在项目文件里，就认为应用已经读取到它。
例如镜像标签可以通过变量替换选择，而数据库密码通常应由受控文件或密钥系统提供。容器环境变量可能被有权限的管理工具读取，也可能被错误日志输出，不应把它视为加密存储。先把非敏感运行参数和敏感凭据分开清点，再决定注入方式。
变量替换需要明确来源和失败条件
${APP_IMAGE:?set APP_IMAGE} 表示变量缺失或为空时让配置处理失败，适合不能默默取默认值的部署参数。命令执行环境中的变量可能覆盖项目环境文件内容，因此发布机和手工终端即便使用同一个 Compose 文件，也可能得到不同结果。
在受控目录里记录本次使用的环境文件、项目路径和镜像标识。不要把完整展开结果直接贴进工单；可以先执行 docker compose config --quiet 做静态校验，它不会输出完整展开配置，但通过也只证明结构有效，不能证明应用已连接成功。Compose 变量替换
按服务授予密钥文件
下面是合并到已有项目的配置示例。APP_IMAGE 应设置为已经审核的固定版本或摘要；相对路径相对于该部署配置的位置进行确认，示例密钥文件必须提前以受控方式创建。
services:
app:
image: ${APP_IMAGE:?set APP_IMAGE}
environment:
APP_MODE: production
secrets:
- db_password
secrets:
db_password:
file: ./secrets/db_password.txt
在这个服务中，文件通常位于 /run/secrets/db_password，但应用必须明确读取该路径。它不会自动变成 DB_PASSWORD 环境变量，也不是任意程序都支持 _FILE 后缀；使用某个镜像的文件型密码变量前，应核对该镜像文档。Compose secrets 使用说明
文件挂载仍需要保护宿主机
本地 Compose 的文件型 secrets 不等于独立加密保险库。宿主机源文件、备份副本、部署账号和拥有 Docker 管理能力的人员仍处于信任范围内。密钥目录不应提交到代码仓库或放在网站可访问目录，源文件权限应结合运行用户验证，避免为解决读取失败改成所有人可读。
只给需要数据库连接的服务声明该密钥，不要让静态页面容器也获得它。验证时检查文件存在、运行用户能读取以及应用认证是否通过，但不要把文件内容打印出来。失败后优先区分文件不存在、权限不符、内容换行处理和数据库认证错误，分别修正。
轮换需要让应用与数据库同步
替换宿主机文件并不意味着全部应用会立即采用新值。应用可能只在启动时读取，连接池也可能继续使用旧认证；部署方式还会影响文件挂载何时反映替换。因此先在测试环境确认读取行为，再按实际部署流程更新目标服务并验证新连接。
更稳妥的切换是先准备具有同等最小权限的新凭据，确认数据库接受，再更新应用并检查后台任务与重连，最后撤销旧凭据。具体数据库是否支持同一账号双密码要按版本确认，不能假设所有服务都支持。回退时保留尚未撤销的受控恢复路径，同时记录新旧凭据状态，避免把已经失效的密码重新部署到应用。