add指令仅在构建时一次性复制文件，无法自动更新配置；所谓“自动更新”实为缓存失效、重建镜像或混淆挂载所致；动态配置应通过绑定挂载、环境变量、配置中心等运行时机制实现。

Dockerfile 中的 ADD 指令本身不具备自动更新配置文件的机制，它只是在构建镜像时将本地文件或远程 URL 内容复制到镜像内指定路径。所谓“自动更新”是常见误解——实际是否生效，完全取决于构建上下文、缓存策略和使用方式。

ADD 的行为本质：一次性复制，非运行时同步

ADD（以及更推荐的 COPY）只在 docker build 过程中执行一次，属于构建阶段操作：

• 构建时读取宿主机上的文件内容，打包进镜像层，与宿主机后续修改完全无关；
• 容器运行后，镜像内的配置文件是静态的，不会随宿主机文件变化而更新；
• 即使重新运行 docker run，只要没重建镜像，配置仍是旧版本。

为什么有人觉得“自动更新”？——缓存与误用场景

某些情况下看似“更新了”，实为构建缓存失效或外部干预导致：

• 修改了 ADD 前的指令（如 RUN、ENV），导致后续层缓存失效，触发重新 ADD；
• 在 CI/CD 流程中每次拉取最新代码并重建镜像，使新配置被 ADD 进新镜像；
• 误将 ADD 和 docker cp、绑定挂载（-v）混淆——后者才支持运行时动态覆盖。

真正实现配置热更新的可行方式

若需让容器使用最新配置，应脱离构建时复制逻辑，改用运行时注入机制：

• 绑定挂载配置文件：启动容器时用 -v /host/config.yml:/app/config.yml:ro，宿主机改完立即生效（需应用支持重载）；
• 通过环境变量或命令行参数传入配置项：在 ENTRYPOINT 脚本中生成配置文件，避免硬编码；
• 使用配置中心（如 Consul、etcd、Spring Cloud Config）：容器启动后主动拉取，支持动态刷新；
• 多阶段构建 + 构建参数（ARG）：在构建时传入配置版本或 URL，由 RUN 指令下载，但仍是静态快照，非自动更新。

ADD 使用建议与风险提示

除非明确需要将配置固化进镜像（如默认兜底配置），否则不推荐用 ADD 管理易变配置：

• 优先用 COPY 替代 ADD，语义更清晰，不支持自动解压和 URL 下载，减少意外行为；
• 确保 Dockerfile 中 ADD 的源路径在构建上下文中存在，且未被 .dockerignore 排除；
• 配置文件含敏感信息时，切勿用 ADD 硬编码进镜像，应改用 secrets 或环境变量注入。

不复杂但容易忽略：ADD 是构建快照工具，不是配置同步服务。要动态，就得在运行时做文章。