Dockerfile中Curl下载部分版本未缓存的原因咨询

API 探路者

2026-7-11

问题

我在Dockerfile中从Apache归档地址下载Nifi安装包，示例命令如下：

RUN curl -fSL ${MIRROR_BASE_URL}/${NIFI_BINARY_PATH} -o ${NIFI_BASE_DIR}/nifi-${NIFI_VERSION}-bin.zip \
    && echo "$(curl ${BASE_URL}/${NIFI_BINARY_PATH}.sha256) *${NIFI_BASE_DIR}/nifi-${NIFI_VERSION}-bin.zip" | sha256sum -c - \
...

我分别下载了1.22.0和1.10.0版本，构建日志显示：

=> CACHED [5/9] RUN curl -fSL https://archive.apache.org/dist//nifi/1.22.0/nifi-toolkit-1.22.0-bin.zip -o /opt/nifi/nifi-toolkit-1.22.0-bin.zip  0.0s
=> CACHED [6/9] RUN curl -fSL https://archive.apache.org/dist//nifi/1.22.0/nifi-1.22.0-bin.zip -o /opt/nifi/nifi-1.22.0-bin.zip      0.0s
=> [7/9] RUN curl -fSL https://archive.apache.org/dist//nifi/1.10.0/nifi-1.10.0-bin.zip -o /opt/nifi/nifi-1.10.0-bin.zip 11.6s

可以看到前两次下载使用了缓存，瞬间完成，但第三次下载总是从服务器重新获取，导致镜像构建耗时较长。

我已经了解到RUN命令对应Docker镜像的一个层，若修改RUN命令的任何部分，Docker会重建对应层，从而重新执行下载操作。我此前一直在修改RUN命令，推测这是重复下载的原因，希望能得到更多补充解释。

回答

你的推测完全正确，核心原因就是Docker的分层缓存机制，这里补充几个关键细节帮你理解：

Docker缓存的判断逻辑
Docker对镜像层的缓存复用，是通过对比当前指令的完整文本哈希值和本地已缓存层的哈希值来决定的。对于RUN命令来说，包括命令里的所有参数、变量展开后的具体值（比如你用ARG/ENV定义的版本号、路径），甚至命令的换行、空格，只要有任何变化，都会导致哈希值不匹配，Docker就会放弃该层的缓存，重新执行这条命令。

你之前频繁修改下载1.10.0版本的那条RUN命令，导致这条指令的哈希值和之前缓存的完全不同，所以每次构建都会重新执行curl下载；而前两条1.22.0的RUN命令没有改动过，哈希值匹配缓存，直接复用已有的镜像层，不需要重新下载。

层顺序对缓存的影响
镜像的层是按构建顺序依次生成的，如果前面的某一层缓存失效（比如修改了前面的RUN/COPY命令），那么后面所有的层都会跟着失效，哪怕后面的命令完全没改。但你的日志里前两层缓存命中，说明前面的层没有变化，问题确实出在第三条RUN命令本身的修改上。
优化建议

把不需要频繁修改的下载命令放在镜像构建的靠前位置，这样缓存能被复用更久，避免后续层改动影响到它。
如果要下载多个版本的包，可以考虑把所有下载命令合并到一条RUN里（用&&连接），这样只要这条命令不修改，整个层都会被缓存；但要注意，这种方式下如果其中一个包需要更新，整个层都会重新下载，需要根据实际情况权衡。
可以用Docker的--mount=type=cache特性，缓存curl的下载目录，即使RUN命令修改，也能复用之前下载的文件，减少下载耗时：

RUN --mount=type=cache,target=/root/.cache/curl \
    curl -fSL https://archive.apache.org/dist/nifi/1.10.0/nifi-1.10.0-bin.zip -o /opt/nifi/nifi-1.10.0-bin.zip

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