Dockerfile中ADD <url>相比RUN wget/curl是否存在缓存优势？

首先给出明确答案：ADD <url>在层缓存失效逻辑上没有任何优势，反而存在不可控的设计缺陷，绝大多数场景下不推荐用它替代RUN指令拉取远程依赖。

层缓存逻辑的实际差异 #

你设想的「Docker依托HTTP缓存规则判断、自动拉取算哈希校验」的逻辑，在Docker的实际实现中根本不存在，两者的缓存逻辑对比如下：

• ADD <url>的缓存逻辑完全是黑盒，且可靠性很差：
  • 20.10版本之前的Docker：只要指令里填写的URL字符串没有变化，无论远程文件内容是否更新、哪怕源站已经把文件替换成完全不同的内容，构建时都会直接命中本地缓存，不会发起任何网络请求校验，非常容易出现构建出来的镜像用了过期依赖的问题。
  • 20.10及之后的版本：仅新增了最基础的校验逻辑——构建时发HEAD请求读取源站的Last-Modified响应头，和本地缓存记录的修改时间比对，时间一致就直接用缓存；既不支持标准HTTP缓存的ETag、Cache-Control、Expires等规则，也不会真的拉取文件计算内容哈希做校验。如果源站不返回Last-Modified头，又会退回到旧版本的逻辑，URL不变就永久命中缓存。
• RUN wget/curl的缓存逻辑完全可控：
  RUN指令的缓存命中规则是透明的——只要前序层全部命中缓存、当前RUN指令的文本内容没有修改，就会命中缓存。你可以根据需求自己控制缓存策略：需要强制拉取最新版本就在指令里加--no-cache参数，需要做版本校验就自己加哈希比对逻辑，需要用HTTP缓存规则就给wget/curl加对应的参数，不会被Docker的隐藏逻辑坑。

选型的核心判断依据 #

你提到的「省去安装wget/curl的步骤」看起来是优点，实际生产中反而会带来更多问题，两者选型可以按下面的规则判断：

• 优先选RUN wget/curl的场景（占90%以上）：
  • 拉取的是压缩包、安装包这类需要后续解压、安装、清理的资源：ADD拉取的资源会单独占一个镜像层，哪怕你在后续RUN层里把下载的包删掉，这个文件依然会残留在ADD对应的层里，平白增大镜像体积。用RUN可以把「安装依赖（含wget/curl）→ 拉取资源 → 校验 → 解压安装 → 卸载wget/curl → 清理临时文件」全流程合并到同一层，最终镜像不会残留任何冗余文件，体积更小。
  • 需要可靠的错误处理：ADD拉取远程资源遇到404、500等错误时，旧版本Docker不会直接构建失败，反而会把错误响应页面当成目标文件存到镜像里，直到容器运行时才会暴露问题；wget/curl遇到非200响应会直接返回非0退出码，构建立刻失败，问题可以提前发现。
  • 需要自定义文件权限：ADD拉下来的文件默认权限是600，如果拉的是可执行二进制，还需要额外写RUN指令加执行权限，反而多了一层，没有省事。
• 可以用ADD <url>的场景：
  仅当你拉取的是内容永久不变、URL永久固定、不需要解压、不需要修改权限的小型文件（比如公钥、固定版本的小配置文件）时，用ADD才是真的省事，也不会踩缓存或体积的坑。

常见误区：不要为了少写一行安装wget/curl的指令就盲目用ADD，生产构建中缓存逻辑可控、镜像体积可控、错误可提前感知，远比少写几行指令重要。

内容的提问来源于stack exchange，提问作者Jon Wolski