go build 放在最后会导致镜像层失效，因为 docker 每行 run 生成新层，若 go build 在 copy . /app 后，仅改一行代码就会使前面所有依赖层（如 go mod download）全部重建；正确做法是先 copy go.mod/go.sum 单独成层并 run go mod download 固化依赖，再 copy 源码和构建。
为什么 go build 放在最后会导致镜像层失效
因为 Docker 构建时每一行 RUN 都生成新层，而 go build 依赖源码和 go.mod。如果把构建命令写在 COPY . /app 之后，哪怕只改一行业务代码，前面所有依赖层（go mod download、go install 等）都得重跑——缓存完全失效。
正确做法是分阶段提取依赖变更点：
-
COPY go.mod go.sum ./必须单独成层，且放在COPY . .之前 - 紧接着用
RUN go mod download固化依赖层，这样只要go.mod不变，这层就复用 - 再
COPY . .和RUN go build，此时只有源码变才触发重建
多阶段构建中 GOROOT 和 GOPATH 怎么设才不踩坑
Go 1.16+ 默认使用模块模式，GOPATH 已非必需；但多阶段构建里若用 golang:alpine 基础镜像，它的 GOROOT 是 /usr/local/go，而 Alpine 的 apk add go 安装路径可能是 /usr/lib/go，混用会报 command not found: go 或 cannot find package。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 统一用官方
golang:1.22-alpine（或对应版本）作为 builder 阶段镜像，避免手动装 Go - build 阶段无需显式设
GOROOT，但要加GOOS=linux GOARCH=amd64（除非你真要 cross-compile） - final 阶段用
scratch或alpine时，别带GOROOT环境变量——静态编译的二进制不依赖它
CGO_ENABLED=0 什么时候必须开，什么时候反而坏事
默认开启 CGO_ENABLED=1，Go 会链接系统 C 库（比如 libc），导致 final 镜像必须包含对应动态库；而 scratch 镜像没任何库，直接运行就报 no such file or directory（其实是找不到 ld-musl 或 ld-linux）。
但有些包绕不开 C：比如 net 包在某些 DNS 场景下依赖 libc 的 getaddrinfo，或者用了 cgo 绑定的 SQLite、OpenSSL。
判断依据：
- 纯 HTTP/JSON/protobuf 服务 → 安全开
CGO_ENABLED=0 - 用了
database/sql+sqlite3或github.com/mattn/go-sqlite3→ 必须关CGO_ENABLED，否则静态链接失败 - 不确定是否含 cgo？构建后用
file your-binary看输出：含dynamically linked就说明没关干净
Dockerfile 中 COPY --from=builder 复制路径写错的典型错误
常见错误是假设 builder 阶段的 WORKDIR 和 final 阶段一致，结果 COPY --from=builder /app/main /app/ 找不到文件——因为 builder 里 go build -o /app/main 实际写入的是 /app/main，但如果你在 builder 里没显式 WORKDIR /app，而用的是默认 /go，那二进制其实在 /go/main。
稳妥写法：
- builder 阶段开头就写
WORKDIR /app，并确保go build -o ./main .输出到当前目录 - final 阶段用
COPY --from=builder /app/main /usr/local/bin/app，路径绝对化，不依赖 WORKDIR - 如果用
alpinefinal 镜像且开了CGO_ENABLED=0，别复制.so文件——它们根本用不上
最易被忽略的一点：builder 阶段的 go build 如果用了 -trimpath 和 -ldflags="-s -w"，不是锦上添花，而是影响调试符号剥离和路径脱敏的关键开关；漏掉的话，镜像体积可能多出几 MB，且日志里暴露本地开发路径。
