配置更新不能依赖dockerfile的add/copy，应分构建时（arg/env）和运行时（挂载/配置中心）注入；构建时适合固定非敏感参数，运行时挂载使配置实时生效，密钥必须用secrets管理。
不能靠 Dockerfile 自动更新配置文件——ADD 或 COPY 指令只在构建时复制一次，之后宿主机改了，容器里不会变。所谓“自动化注入”，其实是选对时机和方式：构建时用 ARG/ENV 注入可变参数，运行时用挂载或配置中心加载实时配置。
构建时注入：用 ARG + ENV 传参生成配置
适合那些在镜像打包阶段就确定、且不敏感的配置，比如环境标识、API 地址前缀、构建时间戳等。
- 在 Dockerfile 中声明构建参数并转为运行时变量：
ARG APP_ENV=dev
ENV NODE_ENV=${APP_ENV}
这样构建时传 --build-arg APP_ENV=prod，生成的镜像里 NODE_ENV 就是 prod，而 APP_ENV 不会残留 - 支持批量加载：准备 build.env 文件（每行 KEY=VALUE），构建时加 --build-arg-file build.env，再在 Dockerfile 中逐个用 ARG 和 ENV 接收
- 动态生成值（如 Git 提交号）：
ENV GIT_COMMIT=$(git rev-parse --short HEAD 2>/dev/null || echo "unknown")
注意：命令在构建机上执行，需确保 git 已安装；生成值会固化进镜像，不可用于密码类信息
运行时注入：绑定挂载最直接有效
真正让配置“活起来”的方式——容器启动后，宿主机改了配置，容器内立刻可见（应用需支持热重载）。
- 用 -v /host/config.yml:/app/config.yml:ro 启动容器，把本地文件映射进去
- 推荐配合 ENTRYPOINT 脚本，在容器启动时根据环境变量生成配置文件：
比如读取 $DB_HOST、$DB_PORT，拼成 config.yml 再写入 /app/config.yml，避免硬编码 - 若应用支持，也可通过命令行参数传配置：
ENTRYPOINT ["sh", "-c", "python app.py --host=$DB_HOST --port=$DB_PORT"]
别踩这些坑
很多“配置没生效”问题，其实源于误用或混淆：
- 别用 ADD 更新配置：它不是同步工具，改了宿主机文件，不重建镜像就永远看不到新内容
- 别在 ENV 里写密码：如 ENV DB_PASSWORD=123，该值会留在镜像层历史中，用 docker history 一眼可见
- .env 文件对 build 无效：--env-file 是 docker run 的参数，docker build 不认它
- 变量展开要加花括号：写成 ${APP_ENV} 而不是 $APP_ENV，尤其拼接路径时（如 /conf/${APP_ENV}.yml）更安全
什么情况该选哪种方式？
简单判断逻辑：
- 配置固定、极少变动、不含密钥 → 构建时用 ARG/ENV 生成或 COPY 默认配置
- 配置常变、需快速生效、应用支持重载 → 运行时用 -v 绑定挂载
- 多环境/多租户/权限敏感 → 上配置中心（Consul、etcd、Spring Cloud Config），容器启动后主动拉取
- 密钥类信息 → 一律用 Docker Secrets 或第三方密钥管理服务，绝不进镜像、不进环境变量明文
