Dockerfile 里 COPY 顺序会直接影响构建缓存

第一次写 Dockerfile 时，很容易把它理解成“按步骤把环境搭起来”就好。
可 2017 年我在反复构建 Node 项目镜像时，越来越明显地感觉到：Dockerfile 里的 COPY 顺序不只是可读性问题，它会直接决定构建缓存是不是容易失效。

为什么顺序这么关键

因为 Docker 镜像构建是按层走的。
前面某一层一变，后面依赖它的层就很可能都要重新执行。
如果你把变化特别频繁的业务代码很早就 COPY 进去，那么后面安装依赖、准备运行环境这些本来可以复用缓存的步骤也会跟着失效。

我后来更喜欢的思路

先复制变化慢的内容，再复制变化快的内容。
在 Node 项目里尤其明显：依赖描述文件和真正业务代码的变化频率通常不一样，把它们拆开处理，缓存命中率会好很多。

小结

Dockerfile 的很多优化都不是魔法，常常只是把变化节奏想清楚。
COPY 顺序看似细节，实际会直接影响构建缓存体感。2017 年以后我写这类文件时，几乎都会先看哪些东西变得快，哪些东西变得慢，再决定拷贝顺序。

而且这件事不只是省几秒构建时间。
缓存命中更稳定之后，开发者对镜像构建结果也会更有预期，不容易出现“怎么我只是改了一行业务代码，却把依赖安装整段都重新跑了”的困惑。对团队协作来说，这种可预期性其实和速度同样重要。