构建层缓存该不该用：先看它解决的问题是不是你的问题

COPY . . 写在装依赖之前，改一行代码就会让整个依赖层失效

它擅长的是依赖不常变的项目；如果你只是CI 里复用缓存，用现成的东西更省事。

先说结论

缓存优化的本质是「把变化慢的放前面」，与技巧无关，与顺序有关

• 适合：依赖不常变的项目
• 不适合：多阶段构建
• 学习成本：构建上下文会把目录打包发送给 daemon，node_modules 几百 MB 白传
• 最大收益：RUN --mount=type=cache 的缓存不进镜像层，但会长期占用 builder 磁盘
• 最大风险：把 COPY . . 放最前面，改一行代码就重装全部依赖

它到底解决什么

COPY . . 写在装依赖之前，改一行代码就会让整个依赖层失效。

换句话说，它把「依赖不常变的项目」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

把 COPY . . 放最前面，改一行代码就重装全部依赖

没写 .dockerignore，.git 和 node_modules 全进了构建上下文

基础镜像用 latest，缓存天天失效还查不出原因

和替代方案比

docker builder prune 默认只清未被引用的缓存，--all 才是全清。

这台工具的关键细节

几个决定长期体验的点：

• 构建上下文会把目录打包发送给 daemon，node_modules 几百 MB 白传
• RUN --mount=type=cache 的缓存不进镜像层，但会长期占用 builder 磁盘
• buildx 默认 builder 的缓存上限约 10GB，超出后按最近使用淘汰

我的建议

缓存优化的本质是「把变化慢的放前面」，与技巧无关，与顺序有关。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• COPY . . 写在装依赖之前，改一行代码就会让整个依赖层失效
• 多阶段构建只有最后阶段的层进镜像，前面的层只留在构建缓存里

工具是解法，不是身份。