go项目docker自动化构建核心是可复现性、镜像最小化与失败可定位；必须显式设置cgo_enabled=0、goos=linux、goarch=amd64（或arm64），禁用动态链接，多阶段分离builder/runner并使用非root用户，ci中需正确缓存gocache和go/pkg/mod、规范镜像tag、显式启用push。
Go 项目集成 Docker 的自动化构建流水线，核心不是“能不能跑起来”，而是“每次构建是否可复现、镜像是否最小、失败是否可定位”。用错阶段或漏掉关键约束，CI 构建出来的镜像可能体积翻倍、启动报 exec format error、甚至因 CGO 问题在 Alpine 上直接 panic。
go build 阶段必须禁用 CGO 并指定目标平台
本地能跑的 Go 代码，放进 Docker 构建后常在容器里崩溃，多数是因为没控制编译时的环境变量。Alpine 或 distroless 镜像不含 glibc，而默认 CGO_ENABLED=1 会链接动态库。
- 始终在构建阶段显式设置
CGO_ENABLED=0 GOOS=linux GOARCH=amd64（ARM64 项目改GOARCH=arm64） - 不要依赖
go env -w或本地~/.bashrc—— CI 环境是干净的，所有变量必须写死在run步骤里 - 如果项目真要启用 CGO（比如调用 C 库），就别用 Alpine，改用
gcr.io/distroless/cc-debian12或带 musl 的alpine:latest，并安装对应工具链
Dockerfile 多阶段必须分离 builder 和 runner 用户权限
很多团队只拆了镜像大小，却把 root 权限一路带到生产镜像里，安全扫描工具一扫就红。
- builder 阶段用
golang:1.22没问题，但 runner 阶段必须用非 root 用户：在 Alpine 中加addgroup -g 61 -f nonroot && adduser -S nonroot -u 61，然后USER nonroot:nonroot -
COPY --from=builder后记得chown -R nonroot:nonroot /app，否则即使切换用户也无权读二进制 - distroless 镜像不带
adduser，得提前在 builder 阶段创建好 UID/GID，并在 runner 阶段用USER 61:61硬编码指定
GitHub Actions 中缓存和镜像标签容易踩的三个坑
缓存没配对、标签打重、推送失败静默，这三件事会让 CI 看似成功，实则部署的是旧版本或损坏镜像。
-
actions/cache@v4必须同时缓存$HOME/go/pkg/mod和$GOCACHE，只缓存一个会导致go test命中率暴跌 - 镜像 tag 别只用
${{ github.sha }}—— Git SHA 在 force push 后会变，导致历史镜像被覆盖；建议组合使用：myapp:${{ github.sha }}-${{ github.run_id }}或语义化版本 + commit，例如myapp:v1.2.0-${{ github.sha }} -
docker/build-push-action@v5默认push: false，漏写push: true就算 build 成功，镜像也不会上传，后续部署永远拉不到新镜像
真正卡住上线的，往往不是语法错误，而是 builder 阶段用了 go run main.go 测试，结果 runner 阶段 COPY 进去的却是未编译的源码；或是 .dockerignore 漏了 go.mod，导致构建时反复下载依赖拖慢流水线。这些细节不会报错，但会让整个自动化失去可信度。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
