Dockerfile 不支持自动化配置更新，仅在构建时静态打包；配置热更新需通过运行时绑定挂载、启动时动态生成或对接配置中心实现。
直接说结论：Dockerfile 本身不支持“自动化配置更新”，它只负责构建时的一次性打包。所谓“自动更新配置”，本质是混淆了构建阶段和运行阶段——真正要实现配置随外部变化而生效，得在容器启动后动手，而不是靠 ADD 或 COPY 指令。
别指望 ADD/COPY 实现热更新
很多人误以为在 Dockerfile 里写上 ADD config.yml /app/config.yml，之后改了宿主机的 config.yml，容器里的配置就会跟着变。事实是：
- ADD 只在
docker build那一刻把当时文件的内容打进镜像层，之后无论宿主机怎么改，镜像内文件完全不受影响； - 哪怕重启容器（
docker restart），只要没重建镜像，用的还是老配置； - 所谓“看起来更新了”，往往是 CI/CD 每次都重新 build、或是误用了
-v挂载，不是 Dockerfile 的功劳。
让配置真正可更新的三种实用方式
想让容器用上最新配置，关键是从运行时入手：
-
绑定挂载（-v）：启动时把宿主机配置文件直接映射进容器，比如
docker run -v $(pwd)/config.yml:/app/config.yml:ro myapp。改完宿主机文件，应用若支持重载（如 Nginx reload、Spring Boot Actuator refresh），就能立刻生效； -
启动时生成配置：Dockerfile 中用 ENTRYPOINT 脚本读取环境变量或 secrets，动态写出配置文件。例如：
echo "host=$DB_HOST port=$DB_PORT" > /app/app.conf，再执行主程序； - 对接配置中心：容器启动后主动调用 Consul、etcd 或 Apollo 接口拉取配置，配合监听机制实现变更自动刷新——这需要应用代码层面支持，但最灵活可靠。
如果非要构建时带配置，注意这几点
某些场景（如默认兜底配置、离线部署）确实需要把配置打进镜像。这时要注意：
- 优先用
COPY替代ADD，语义明确，不触发意外解压或远程下载； - 确保配置文件没被
.dockerignore忽略，且路径相对构建上下文正确； - 含密码、密钥等敏感信息的配置，绝不能硬编码进镜像，应通过
docker run --secret或环境变量注入； - 若配置来自外部 URL 或 Git 仓库，可用多阶段构建 +
RUN curl …下载，但它仍是构建那一刻的快照，不是持续同步。
配套自动化建议（非 Dockerfile 责任，但很关键）
Dockerfile 是静态构建脚本，自动化更新得靠外部协同：
- CI 流水线中，代码提交后自动
docker build && docker push，再触发生产环境docker pull && docker run——这是“镜像级更新”； - 用 Watchtower 监控运行中容器，发现远端镜像有新 tag 就自动拉取并重启——适合基础镜像或小版本迭代；
- 对测试类容器（如自动化测试框架），推荐每次代码更新都重建镜像，避免配置残留导致误判。
不复杂但容易忽略：Dockerfile 是快照工具，不是同步服务。配置要活，就得在容器跑起来之后想办法。
