docker compose变量优先级由高到低为：service environment显式值＞env_file文件＞.env文件＞宿主机shell变量；默认值推荐用${var:-default}防空值；多环境应分离为.env.common、.env.development等；敏感信息须用secrets或权限受限的env_file隔离。
直接用好变量替换，关键不在语法多复杂，而在来源清晰、覆盖可控、默认可靠。docker compose 的变量机制不是“能不能用”，而是“怎么让每一层值都按预期生效”。
变量来源优先级必须理清
同名变量在不同位置定义时，最终进容器的是哪一个？答案取决于四层顺序（由高到低）：
-
service 级 environment 字段中显式写死的值：例如
environment: - DB_HOST=prod-db，最高优先级，直接覆盖所有外部来源 -
env_file 指定的文件内容：如
env_file: [".env.production"]，加载时机早于 .env，可精准控制环境特有配置 -
项目根目录下的 .env 文件：自动加载，适合本地开发默认值；但不应含敏感信息，且需加入
.gitignore -
宿主机 shell 中已 export 的变量：最低优先级，仅作后备；若想强制生效，需提前
export VAR=value再执行docker compose up
默认值语法要分清两种空场景
`${VAR:-default}` 和 `${VAR-default}` 看似一样，实则行为不同：
-
${VAR:-default}：当VAR未设置 或值为空字符串（如VAR=""）时，才启用default -
${VAR-default}：仅当VAR完全未定义（连空字符串都没有）时，才启用default
实际建议统一用 :- 形式——它更安全，能防住“设了空值却意外走默认”的坑。比如 PORT=${PORT:-3000} 可确保即使 .env 里写了 PORT=（空），也不会崩。
多环境文件组合是企业级标配
单靠一个 .env 不足以支撑 dev/test/prod 分离。推荐结构如下：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
-
.env.example：提交到 Git，只列 KEY 名和注释，不带真实值，供新成员快速上手 -
.env：本地默认，含开发常用值（如DB_HOST=localhost），加进 .gitignore -
.env.common：通用配置（如日志级别、基础路径），被所有环境复用 -
.env.development/.env.production：环境专属，含连接串、密钥等，不提交
在 docker-compose.yml 中这样引用：
- .env.common
- .env.${ENV_TYPE}
启动时只需 ENV_TYPE=production docker compose --env-file .env.production up，双保险加载。
敏感信息必须隔离处理
密码、API Key、私钥等绝不能出现在 docker-compose.yml 或 .env 明文里。正确做法是：
- 用
secrets字段配合 Docker Swarm 或 Compose v2.20+ 的内置 secret 支持 - 或改用
env_file指向权限受限的文件（如chmod 600 .env.secrets），并确保该文件不被 CI/CD 流水线误传 - CI 环境中通过平台原生 secret 注入（如 GitHub Actions 的
secrets、GitLab CI 的variables），再通过-e KEY=传入
记住：任何写进文本文件的密钥，只要文件可读，就等于暴露。
