BuildKit 缓存复用是什么
把构建缓存导出到镜像仓库或共享后端（--cache-to / --cache-from）：换机器、换流水线也能吃到缓存，构建显著提速。BuildKit 是 buildx 的默认构建引擎；缓存可以随镜像内联（inline），也可以独立导出到 registry。前者简单但保留有限，后者 mode=max 能含中间层，适合多阶段构建。
基本信息
| 方式 | registry 缓存（mode=max 含中间层）、inline（随镜像附带，能力有限）、CI 平台缓存后端 |
|---|---|
| 命令 | docker buildx build --cache-from type=registry,ref=... --cache-to type=registry,ref=...,mode=max |
| 平台 | GitHub Actions 可用 --cache-to type=gha |
| 命中条件 | 指令与文件内容一致，命中后跳过对应构建步骤 |
| 体积 | 缓存独立于镜像：用单独命名空间与清理策略 |
典型使用场景
- 多阶段构建：依赖层与编译层分离，最大化缓存复用
- 多 Runner：缓存推到 registry，弹性机也能复用
- CI 提速：冷启动机器不再从零编译
- 分支隔离：按分支或目标使用不同缓存命名，避免串味
- 平台缓存：GitHub Actions 用 gha 后端简化配置
- 缓存治理：定期清理旧缓存，控制仓库增长
实践要点
- 缓存键设计：基础镜像、依赖清单与构建参数变动要能失效
- 先拉后推：构建开始先 cache-from，结束再 cache-to
- 命名隔离：缓存 tag 与发布 tag 分开，避免互相覆盖
- 命中验证：看日志里的 CACHED 标记确认生效
- 体积监控：mode=max 缓存可观，设容量与清理策略
- 依赖顺序：变化最频繁的层放在构建文件后段
- 失败隔离：缓存损坏时允许回退全量构建，别卡死流水线
registry 缓存
registry 缓存
docker buildx build \
--cache-from type=registry,ref=registry.example.com/app:buildcache \
--cache-to type=registry,ref=registry.example.com/app:buildcache,mode=max \
-t registry.example.com/app:1.8.0 --push .缓存方式对照
| 方式 | 保留范围 | 适用 |
|---|---|---|
| inline | 随镜像的最终层 | 简单场景 |
| registry mode=min | 导出的少量层 | 基础复用 |
| registry mode=max | 全部中间层 | 多阶段构建 |
| gha 后端 | 平台缓存服务 | GitHub Actions |
缓存导出体积可观：registry 侧为缓存镜像设置独立的清理策略。
命中与否看日志：CACHED 标记出现即命中，没有就先检查键与来源。