BuildKit 默认未启用，需通过环境变量或配置文件显式开启；Go项目构建须分层：先COPY go.mod/go.sum并RUN go mod download，再COPY源码，最后构建；推荐golang:1.22-alpine用于纯Go项目，golang:1.22用于需系统库的场景。
BuildKit 默认没开，得手动启用
Go 项目用 docker build 时默认走传统 builder，BuildKit 不生效——哪怕你装的是新版 Docker。不显式开启，go build 的中间产物、依赖下载、vendor 缓存全被丢弃，每次都是从零开始。
启用方式只有两个可靠路径：
- 环境变量：
DOCKER_BUILDKIT=1（Linux/macOS）或set DOCKER_BUILDKIT=1（Windows cmd） - 配置文件：
{ "features": { "buildkit": true } }写进~/.docker/config.json
别信某些文档说“Docker 23+ 自动启用”，实测不设就不用 BuildKit；也别在 Dockerfile 里加注释触发，那只是提示，不是开关。
Go 构建阶段必须分层，否则缓存形同虚设
BuildKit 的缓存能力依赖指令顺序和内容稳定性。go mod download 和 go build 如果混在同一个 RUN 里，只要源码一改，前面的模块下载就失效——因为整个 RUN 层哈希全变了。
立即学习“go语言免费学习笔记（深入）”；
正确分层逻辑是：
- 先
COPY go.mod go.sum .→ 触发go mod download，这步独立成层，只要依赖没变，后续构建直接复用 - 再
COPY . .→ 放源码，这步变动频繁，但不影响上层缓存 -
go build放最后，它依赖前两层，但自身不污染前面缓存
示例关键片段：
COPY go.mod go.sum . RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -o /app/main .
注意：go.sum 必须一起 COPY，否则 go mod download 可能校验失败；CGO_ENABLED=0 不是可选，它让二进制静态链接，避免 Alpine 镜像里缺 libc 而运行报错。
多阶段构建里，builder 镜像选 alpine 还是 golang:xx？
用 golang:1.22-alpine 看似轻量，但 Alpine 的 musl 和 Go 工具链偶尔有小版本兼容问题（比如某些 cgo 依赖或 go install 工具链路径异常）；而 golang:1.22（即 Debian 基础）更稳，但镜像大 300MB+，首次拉取慢。
权衡建议：
- 纯 Go 项目（无 cgo）、CI 环境带镜像缓存 → 选
golang:1.22-alpine，构建快、最终镜像小 - 本地开发调试频繁、或用了
net/http/pprof等隐式依赖系统库的包 → 用golang:1.22，省去排查musl相关 panic 的时间 - 千万别用
golang:latest，Go 小版本升级可能破坏go.sum校验或引入新编译警告
缓存不命中？先查 build cache 是否真被复用
BuildKit 缓存是否生效，不能只看终端有没有 “CACHED” 字样——有些日志是假的，尤其当你用了 --no-cache 或 CI 环境没配 cache-from。
验证方法很简单：
- 加
--progress=plain参数重跑一次构建，观察每行输出里的CACHED或...（表示跳过）是否出现在go mod download和RUN go build步骤 - 检查
docker buildx du -v输出，看是否有大量 “unused” cache，说明缓存策略没对上 - CI 场景下，必须显式传
--cache-from type=registry,ref=your-registry/cache:go-build并配合--cache-to，否则每次都是冷启动
常见误判点：本地开发反复改 main.go，却指望 go mod download 缓存失效——其实它根本不会失效，问题出在你把 COPY . . 放太早，导致 go.mod 后续被覆盖，缓存链断了。
