docker构建变慢的根源在于未对齐go缓存机制：go.mod/go.sum必须前置copy、cgo_enabled=0必须显式设置、$gocache需挂载，三者缺一都会导致全量重编。
根本不是“Go编译慢”，而是 Docker 构建流程没对齐 Go 的缓存机制——go.mod 放错位置、CGO_ENABLED 没关、$GOCACHE 没挂载，三者任一缺失都会让构建退化为全量重编。
go.mod 和 go.sum 必须在 COPY . . 之前单独复制
Docker 缓存失效是容器内 Go 构建变慢的头号原因。只要 go.mod 或 go.sum 变更，后续所有层（包括 go mod download）都得重跑；但如果它们被裹在 COPY . . 里，哪怕只改一行业务代码，也会导致依赖下载重新触发。
-
COPY go.mod go.sum ./必须紧接在WORKDIR之后，且早于任何其他COPY - 不要写成
COPY . .再RUN go mod download—— 这会让每次源码变更都强制重下全部依赖 - 如果项目用了
replace或私有模块，记得在RUN go mod download前加ENV GOPROXY=https://proxy.golang.org,direct和GOPRIVATE=git.example.com
CGO_ENABLED=0 不是可选，是必须显式设置
容器里默认启用 cgo，一旦依赖里有 net（DNS 解析）、os/user 或第三方包调用 C 函数，就会触发动态链接，不仅编译失败，还会污染 $GOCACHE —— 同一 commit 下，CGO_ENABLED=1 和 CGO_ENABLED=0 的缓存完全不共享。
- 在
FROM golang:1.22 AS builder后立即写ENV CGO_ENABLED=0，比在go build命令前加更可靠 - 若真需 cgo（如用
sqlite3），第二阶段不能用scratch，得切到debian:slim并apt install libc6 - 静态编译还能顺便解决
no such file or directory错误——这是scratch镜像里缺/lib/ld-musl-x86_64.so.1的典型表现
go build 必须带 -mod=readonly 和 -trimpath
这两个参数直接决定 $GOCACHE 能否复用。没有 -mod=readonly，go build 可能悄悄改 go.mod 导致缓存失效；没有 -trimpath，不同机器上编译路径不一致，哈希值就不同，缓存命中率归零。
- 日常构建命令应为：
go build -mod=readonly -trimpath -ldflags="-s -w" -o app ./cmd/app -
-ldflags="-s -w"不仅减体积，还避免调试符号干扰缓存一致性 - CI 环境中务必挂载
$GOCACHE目录（如/root/.cache/go-build），否则每次都是空缓存起步
大型项目要跳过全量扫描，只编译变更包
单体项目或 monorepo 里，90% 的提交只动几个包。用 go build ./... 是拿锤子砸芝麻——它会扫描整个模块树，连没改过的 internal/logging 都重编一次。
- 查变更包：
git status --porcelain | grep '\.go$' | xargs dirname | sort -u | xargs go list -f '{{.ImportPath}}' - 只构建这些包：
go build $(上述命令)，前提是项目没混用vendor和go.mod - 若用了
go mod vendor，得先go list -mod=vendor，否则go list会忽略 vendor 目录
最易被忽略的点：Docker 构建时 $GOCACHE 默认不持久化，而 Go 的缓存目录路径又因系统而异——Linux 是 $HOME/.cache/go-build，macOS 是 $HOME/Library/Caches/go-build，但容器里 $HOME 往往是 /root，没人检查这个路径是否真的有空间、是否被挂载。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
