ADD 远程 URL 会破坏 Docker 构建缓存，因每次构建都需重下载且无法预判内容哈希，导致性能下降和镜像不一致；推荐用多阶段构建配合 curl、显式缓存和校验替代。
Dockerfile 中使用 ADD 指令直接从远程 URL 下载大文件（如 ADD https://example.com/large.tar.gz /app/）会导致显著的构建性能下降，根本原因在于 Docker 的分层缓存机制与网络操作不可分割性之间的冲突。
ADD 远程 URL 会破坏构建缓存
Docker 在遇到 ADD 时，无法对远程资源做内容哈希预判——它必须在每次构建时发起真实 HTTP 请求，下载并校验文件后，才决定是否复用后续层。即使远端文件未变，只要 URL 字符串不变，Docker 仍需重下载；若远端文件已更新，还会导致意外的镜像不一致。
- 每次构建都触发完整下载，无法跳过
- 网络波动或 CDN 缓存失效会延长构建时间，甚至失败
- 无法利用本地构建缓存加速 CI/CD 流水线
推荐替代方案：分阶段 + curl/wget + 显式缓存控制
将下载与解压拆到多阶段构建中，并借助 RUN --mount=type=cache 或本地临时文件缓存，可大幅提升复用率和稳定性。
- 第一阶段用
curl -fSLO下载，配合--retry和--fail提高健壮性 - 使用
RUN --mount=type=cache,target=/root/.cache/curl复用已有下载（需 Docker 23.0+） - 通过
sha256sum校验文件完整性，避免因网络截断导致构建成功但运行失败 - 大文件解压建议在独立
RUN层完成，防止 tar 包残留影响缓存粒度
避免在生产 Dockerfile 中直接 ADD 远程资源
该写法虽简洁，但违背了“可重现构建”原则。CI 环境无代理、DNS 变更、证书更新等都可能让构建突然中断。更可靠的做法是：
- 将大文件预置到私有镜像仓库或内网 HTTP 服务，配合固定版本路径（如
/v1.2.3/app-bundle.tgz） - 在构建前用脚本下载并校验，再通过
docker build -f Dockerfile --build-arg BUILD_CONTEXT=./downloads .注入本地文件 - 对开源项目，优先使用包管理器（
apt install、apk add、pip install --no-cache-dir）替代手动下载
本质不是 ADD 指令慢，而是它把网络不确定性带进了本应确定的构建过程。控制输入来源、显式管理缓存、分离下载与安装，才能真正释放 Docker 构建效率。
