ADD 从 URL 下载不推荐，因其无法校验完整性、URL 失效导致构建失败、缓存失效且违反确定性原则；应改用 RUN curl/wget 配合 SHA256 校验和清理步骤。
ADD 支持从远程 URL 下载文件，但仅限构建时静态获取，不适用于运行时动态拉取。Docker 官方明确建议：优先使用 COPY 处理本地文件，远程资源尽量用 RUN wget 或 RUN curl 替代 ADD，以提升可复现性、安全性和镜像透明度。
为什么 ADD 从 URL 下载不推荐？
ADD 指令在遇到 HTTP/HTTPS URL 时会自动下载并解压（若为归档格式），看似方便，但存在几个关键问题：
- 无法校验下载内容完整性（无内置 SHA256 校验机制）
- URL 变更或失效会导致构建失败，且错误信息不直观
- 缓存机制对远程 URL 不生效（每次构建都重新下载，拖慢速度）
- 违反“构建阶段确定性”原则——镜像应可重复构建，而远程资源不可控
更可靠的做法：RUN + curl/wget + 验证
显式使用 RUN 执行下载，并搭配校验和与清理步骤，逻辑清晰、易于调试：
RUN set -eux; \
curl -fsSL "https://example.com/app-v1.2.0.tar.gz" -o /tmp/app.tar.gz; \
echo "a1b2c3... /tmp/app.tar.gz" | sha256sum -c -; \
tar -xzf /tmp/app.tar.gz -C /usr/local/; \
rm /tmp/app.tar.gz
-
set -eux确保任一命令失败即中断构建 -
curl -fsSL静默失败、跟随重定向、忽略证书警告（生产环境建议加--cacert） - 用
sha256sum -c校验哈希值，防止中间人篡改 - 下载后立即清理临时文件，减小镜像体积
如果坚持用 ADD（不推荐但兼容旧写法）
语法简单，但需注意限制：
- 仅支持 HTTP/HTTPS，不支持 FTP、SFTP 或带认证的 URL（如
https://user:pass@host/file） - 不会自动校验、不会重试、不支持断点续传
- 若 URL 返回压缩包（.tar、.tar.gz、.tgz、.bz2、.xz），ADD 会自动解压到目标路径
- 示例（不推荐）：
ADD https://example.com/config.json /app/config.json
替代方案：多阶段构建中预下载
对大型依赖（如 Node.js 包、Python wheel），可单独用一个 builder 阶段下载并缓存：
FROM alpine AS downloader
RUN apk add --no-cache curl && \
curl -fsSL https://example.com/binary -o /bin/app && \
chmod +x /bin/app
FROM alpine
COPY --from=downloader /bin/app /usr/local/bin/app
- 利用构建缓存加速重复下载（只要 URL 和命令不变，builder 阶段可复用）
- 主镜像不含下载工具和临时文件，更精简安全
- 适合 CI/CD 中需要稳定、可审计的二进制分发场景
