Docker 构建缓存优化器

要解决的问题

在常规 docker build 流程里，层缓存看似好用，实际很容易失效：改一行依赖版本会连带打掉后续 RUN 与 COPY，大型 RUN 每次都把包管理器缓存重新下载；COPY 顺序不讲究，源码一变就让本该稳定的构建层整体作废；最终镜像里还可能留下早期阶段的依赖和中间产物，体积和构建时间一起膨胀。

技能如何工作

该技能围绕“先看清缓存，再重构 Dockerfile”展开，核心能力包括：基于 BuildKit 的 cache mount 分析、通过 docker history 检查镜像层，以及使用 hadolint 做 Dockerfile 静态检查。

• 缓存挂载分析：定位可从 RUN 中提取的依赖目录，建议使用 --mount=type=cache,target=/var/cache/apt,... 等方式，让包管理器缓存跨构建复用。
• 层历史检查：用 docker history 查看每层的体积、父链和变更点，识别“大且频繁重建”的层，判断是依赖下载、编译产物，还是 COPY 顺序问题。
• Dockerfile 规范检查：用 hadolint 找出高风险写法，如未固定的基镜像、不推荐的指令组合和潜在可缓存却不稳定的模式。
• 层顺序重构：把变化频率低、影响面大的步骤前置；拆分 COPY，让依赖清单先复制、再复制源码；合并或重排 RUN，避免缓存被细碎变更连续击穿。
• 多阶段构建：把构建期依赖和工具留在 builder 阶段，仅把运行期需要的二进制、配置和静态资源复制到最终阶段，减少无效层和镜像体积。

适用边界与注意点

• 该技能侧重 Dockerfile 与层结构层面的可优化空间，不能替代网络加速、私有 registry、增量编译等基础设施改造。
• cache mount 适合可下载、可缓存的目录（如 apt、pip、npm），不适合依赖实时状态或不保证幂等的路径。
• 过度合并 RUN 会牺牲可读性和缓存粒度，层顺序调整需结合真实变更频率做权衡。
• 基础镜像升级、依赖源替换、安全补丁等变更，应在“低频大层”与“可预测重建”之间找到平衡点。
• 项目来自 Moby/Docker 生态的上游文档与实践，需按当前 BuildKit、Docker Engine 与 hadolint 规则版本校准建议。