优先使用 copy，仅在需自动解压或远程下载时用 add；因 add 易导致缓存失效、镜像体积膨胀、网络不可靠及语义模糊，而 copy 更稳定、可控、安全且符合最佳实践。
优先用 COPY，只在明确需要自动解压或远程下载时才考虑 ADD。这不是风格偏好，而是构建稳定性、缓存效率和镜像体积的硬性要求。
缓存失效风险：ADD会让整条流水线变慢
ADD 指令一旦涉及文件变更（哪怕是压缩包内部某个小文件改了），Docker 就无法准确感知变化点，导致该层及后续所有层缓存失效。这意味着每次构建都要重跑依赖安装、编译等耗时步骤。
- COPY 只校验源文件内容哈希，内容不变就复用缓存，稳定可靠
- ADD 对 tar.gz 等归档的解压行为是“黑盒”操作，Docker 不追踪解压后文件树，缓存逻辑断裂
- 真实案例中，某团队因 ADD project.tar.gz 导致 npm install 层反复重建，单次构建延长 2.3 分钟
镜像体积失控：自动解压悄悄塞进隐藏文件
ADD 解压时不会过滤 .git、__pycache__、node_modules 或临时日志，这些本该被 .dockerignore 排除的内容，可能直接打进镜像底层，且无法通过后续 RUN rm 清理——因为它们属于 ADD 层，不可变。
- COPY 把压缩包当普通文件处理，体积可控，解压时机和路径完全由你掌控
- 推荐组合：COPY app.tar.gz /tmp/ && RUN tar -xzf /tmp/app.tar.gz -C /app && rm /tmp/app.tar.gz
- 这样既能精准指定解压目标，又能立刻清理中间文件，避免冗余层残留
远程资源引入：ADD 的 URL 功能暗藏不可靠性
ADD https://xxx.tgz /app/ 看似简洁，但构建过程强依赖网络、无认证支持、失败不提示具体原因，CI 流水线容易随机中断。
- 更健壮的做法是用 RUN curl -fsSL | tar -xzf - -C /app，可加重试、校验、超时控制
- 若必须用 ADD 下载，务必放在 Dockerfile 最末尾，避免污染前面所有缓存层
- 注意：ADD 不支持 HTTP Basic Auth，私有仓库资源一律改用 RUN + curl/wget
语义清晰性：影响团队协作与长期维护
一个 COPY 指令，开发者一眼就知道“这里只是复制”，而 ADD 可能触发下载、解压、权限变更等多种行为，阅读 Dockerfile 成本上升，误改风险提高。
- 官方文档明确建议：除非需要 ADD 的额外能力，否则始终使用 COPY
- CI/CD 审计工具（如 Hadolint）默认对 ADD 发出警告，强制团队思考“是否真有必要”
- 统一用 COPY 后，Dockerfile 更易做静态分析、自动化优化和安全扫描
