批量部署需环境变量与自定义镜像协同设计：镜像固化运行时结构并支持参数化（arg/env），环境变量分层覆盖（-e > env_file > env默认值），配置外置、敏感信息不入镜像。
批量部署时，环境变量和自定义镜像不是两个孤立环节，而是需要协同设计的一体化方案。核心在于：镜像负责固化运行时结构，环境变量负责注入差异化配置；镜像应具备“可参数化”能力，而非硬编码所有值。
镜像构建阶段：用 ARG + ENV 实现参数化
Dockerfile 中需区分构建期变量与运行期变量：
-
ARG 用于接收
docker build --build-arg传入的值，仅在构建过程中有效，适合版本号、构建路径等不随环境变化的参数 -
ENV 设置的变量会写入镜像层，容器启动后仍存在，适合默认值或通用配置（如
LANG=C.UTF-8） - 推荐写法：先用
ARG接收值，再用ENV赋默认或覆盖值，例如：ARG APP_ENV=prod<br>ENV APP_ENV=${APP_ENV}
容器运行阶段：分层覆盖环境变量
变量来源有优先级顺序，高优先级覆盖低优先级：
- 容器启动时
-e KEY=VALUE指定的值（最高优先级） -
env_file文件中定义的变量（常用于 docker-compose.yml） - 镜像中
ENV指令预设的默认值（最低优先级）
例如，在 CI/CD 流水线中，可统一使用 .env.production 和 .env.staging 文件，配合 docker-compose --env-file 切换环境，避免修改代码或镜像。
自定义镜像分发：保持镜像纯净，配置外置
真正可复用的镜像不应绑定具体环境值：
- 禁止在 Dockerfile 中直接写
ENV DB_HOST=10.0.1.5这类生产地址 - 允许写
ENV DB_HOST=localhost作为开发默认值，但必须能被运行时覆盖 - 若应用需动态替换配置文件（如 Nginx conf、Spring Boot 的 application.yml），建议搭配
ENTRYPOINT脚本读取环境变量并渲染模板，而不是把配置 baked 进镜像
批量部署实践要点
面向多环境（dev/test/prod）批量部署时：
- 构建一次镜像，打一个 tag（如
myapp:v1.2.0），不为每个环境构建不同镜像 - 用部署工具（Ansible / Argo CD / Jenkins Pipeline）控制
--env-file或-e参数，实现“同一镜像、不同配置” - 敏感变量（密码、密钥）绝不进镜像、不进 Git，通过 Secret 对象（K8s）、Vault 或宿主机挂载方式注入
