容器镜像构建慢主因是缓存未合理利用，关键在于理解分层机制（只读快照链）、分层内容放置策略（稳定操作靠前、易变操作靠后）、缓存失效规则（哈希变化导致后续全重建），并借助BuildKit缓存挂载与多阶段构建提升复用率。
容器镜像构建慢，往往不是因为机器性能差，而是缓存没用对。核心在于理解分层怎么工作、哪一层该放什么、以及缓存何时会失效。
分层本质是只读快照链
Docker 镜像由多个只读层叠加而成，每条 Dockerfile 指令（FROM、RUN、COPY 等）生成一个新层。这些层通过联合文件系统（如 overlay2）合并成统一视图。关键点在于：
- 每一层只记录与前一层的差异，不重复存储相同内容
- 层按顺序堆叠，上层可覆盖下层同名文件
- 层通过 SHA-256 哈希唯一标识，内容一变哈希就变，缓存即失效
缓存命中依赖指令顺序和内容稳定性
构建时，Docker 逐层比对哈希：当前层未变 → 复用缓存；一旦某层哈希不同 → 后续所有层全部重建。因此要让“稳定”的操作靠前、“易变”的操作靠后：
- 先 COPY package.json 和 yarn.lock（或 go.mod/go.sum），再 RUN 安装依赖
- 避免 COPY . . 这种全量拷贝——改一行代码就让整个源码层失效
- 把基础镜像选择、环境变量设置、依赖安装等低频变更操作放在前面
BuildKit 提供更精细的缓存控制
启用 BuildKit（通过 DOCKER_BUILDKIT=1 或 daemon 配置）后，可以使用 cache mounts 实现编译中间产物复用：
- Go 项目中，用 --mount=type=cache,target=/go/pkg/mod 缓存模块下载
- Node.js 项目中，挂载 node_modules 目录为 cache mount，避免重复 install
- 支持远程缓存导出（--cache-to type=registry），在 CI 中跨构建节点复用
多阶段构建进一步隔离缓存边界
将构建过程拆成 build stage 和 runtime stage，不仅减小最终镜像体积，也天然隔离缓存影响范围：
- build stage 负责编译、打包，可包含完整工具链和缓存挂载
- runtime stage 只 COPY 编译产物，不带任何构建依赖，缓存更轻量、更稳定
- 两个阶段各自独立缓存，修改源码不影响 runtime 层，反之亦然
