Docker 镜像复制中 COPY 缓存机制如何学

Docker COPY缓存失效会连带重做后续所有层；其输入包括源文件内容哈希、COPY指令写法及前面所有指令，任一变化即导致该层及之后全重建。

学 COPY 缓存机制，核心不是背概念，而是理解“哪变了会连带重做”，然后动手验证。

先抓住最要紧的一点

Docker 构建时每条指令生成一层，缓存复用的前提是：这一层的输入没变，且它上面所有层也没变。而 COPY 指令的“输入”，就是你本地要复制的文件内容（按哈希算）+ Dockerfile 里那行 COPY 的写法 + 它前面所有指令都一致。只要其中任意一项变了，这一层就失效，它后面的所有层全得重来。

按实际构建逻辑分几步学

1. 看懂缓存是否命中

   构建时终端输出里出现 Using cache 就是命中；出现 Running in xxx 或直接执行命令，说明这层及之后全重建了。别只看时间，要看日志里的关键词。

2. 亲手试一次“改代码却重装依赖”

   写个简单 Node.js 的 Dockerfile：先 COPY src/，再 COPY package.json，最后 RUN npm install。改一行 src/index.js，重新 build —— 你会发现 npm install 又跑了一遍。再把顺序调成先 COPY package.json、RUN npm install、再 COPY src/，同样改 index.js，这次 install 那步就显示 Using cache。

3. 搞清哪些操作真会破缓存

   1. ✅ 文件内容变了（哪怕只加个空格）
   2. ✅ 文件权限或修改时间被意外更新（比如某些编辑器保存时重写时间戳）
   3. ✅ .dockerignore 漏写了日志文件或 node_modules，导致它们被纳入构建上下文，哪怕没 COPY 也会让缓存不稳定
   4. ❌ 改 Dockerfile 注释、调整空行、换行符类型（除非影响 COPY 路径解析）

4. 用多阶段构建隔离易变部分

   把编译、打包这些耗时又容易因源码变动触发重建的步骤，放到独立的 builder 阶段。最终镜像只 COPY 编译好的产物，不带源码、依赖安装过程。这样主构建流程几乎不受日常开发改动影响。

不复杂但容易忽略。