Go项目CI流水线需显式设置GOOS/GOARCH/CGO_ENABLED、配对缓存GOCACHE与go/pkg/mod、强制启用-race和覆盖率阈值、使用唯一Docker tag及修正文件权限，缺一不可。
Go 项目 CI 流水线不是“装个 Go 就能跑”，而是必须显式控制环境变量、缓存路径、构建目标和测试行为——漏掉任一环，CI 就可能通过但产物不可用。
GOOS/GOARCH 和 CGO_ENABLED 必须硬编码在 build 步骤里
本地 go build 成功，CI 构建后容器启动报 exec format error 或 panic，90% 是没设平台和链接模式。Alpine 镜像不含 glibc，CGO_ENABLED=1 默认会动态链接失败。
- 所有
go build命令前必须加环境变量：CGO_ENABLED=0 GOOS=linux GOARCH=amd64（ARM64 项目改GOARCH=arm64） - 别依赖
go env -w或 shell profile —— GitHub Actions 的 runner 是干净 Ubuntu，变量只对当前 step 生效 - 若真要启用 CGO（如调用 SQLite C API），就放弃 Alpine，改用
gcr.io/distroless/cc-debian12，并在 builder 阶段安装gcc和对应头文件
缓存 GOCACHE 和 go/pkg/mod 必须配对且路径准确
只缓存 go/pkg/mod 而不缓存 $GOCACHE，会导致 go test -race 每次重编译，CI 时间翻倍；反之只缓存 GOCACHE，go mod download 仍频繁拉包。
- GitHub Actions 中用
actions/cache@v4，两个路径都要声明：$HOME/go/pkg/mod和$GOCACHE -
key应包含 Go 版本和go.sumhash，例如：go-mod-v2-${{ hashFiles('**/go.sum') }}-${{ matrix.go-version }} - 不要用
~/.cache/go-build这类模糊路径——$GOCACHE才是 go 工具链实际读写的变量
测试阶段必须启用竞态检测且覆盖率有阈值
仅跑 go test ./ 会漏掉数据竞争和边界逻辑问题，而没有覆盖率门槛的流水线容易让低覆盖代码合入主干。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 测试命令写成：
go test -race -covermode=count -coverprofile=coverage.out ./... - 用
go tool cover -func=coverage.out | grep "total:"提取总覆盖率，低于 75% 就exit 1 - 竞态检测（
-race）不能只在 PR 时开——它会显著拖慢执行时间，但必须在每次 push 到main时强制运行
Docker 镜像 tag 不能只用 commit SHA
myapp:${{ github.sha }} 看似唯一，但 force push 后 SHA 变更，旧镜像被覆盖，K8s 滚动更新可能拉到损坏版本。
- 推荐组合 tag：
myapp:${{ github.sha }}-${{ github.run_id }}（run_id 全局唯一且不可复用） - 生产环境建议加语义化前缀：
myapp:v1.2.0-${{ github.sha }}，并配合 Git tag 触发发布流程 - 推送前加校验：
docker build -t $IMAGE_TAG . && docker push $IMAGE_TAG || exit 1，避免构建成功但推送静默失败
最易被忽略的是：runner 用户权限和二进制文件属主不一致导致容器启动 Permission denied——COPY --from=builder 后必须 chown -R nonroot:nonroot /app，哪怕用了 USER nonroot。这点在 distroless 镜像里尤其致命，因为没 adduser 命令可用，只能靠 UID 硬编码对齐。
