go项目ci/cd失败主因是环境不一致、依赖未锁死或产物路径失控；须提交go.sum、执行go mod tidy、禁用gosumdb=off、显式设goproxy/gocache、硬编码build输出与ldflags、导出coverage.txt并校验阈值。
Go 项目跑 CI/CD 流水线，不配好容器环境和构建路径，90% 的失败都卡在 go build 找不到模块、go test 因竞态挂掉、或者镜像里二进制一运行就报 no such file or directory——根本不是代码问题，是构建上下文没对齐。
go mod tidy 和 go.sum 必须一起提交，否则 CI 构建必然错乱
CI 环境是干净容器，没有本地 go/pkg/mod 缓存，也不走你本机的 GOPROXY。不提交 go.sum，go build 就会重新解析依赖树，可能拉到带 breaking change 的次版本；不运行 go mod tidy -v，go.mod 里可能残留已删包的引用，导致编译时 panic。
- 每次 PR 前本地执行：
go mod tidy -v && git add go.mod go.sum - GitHub Actions 中禁用
GOSUMDB=off——它等于主动放弃供应链校验 - 在 workflow 里加一步验证：
go mod verify，失败则直接退出
go build 输出路径和 -ldflags 必须硬编码，别信默认行为
不指定 -o，go build 默认把可执行文件丢当前目录，后续 Dockerfile COPY 或部署脚本根本找不到；不用 -ldflags="-s -w"，二进制会带调试符号，体积翻倍且暴露内部路径（比如 /home/runner/work/...）。
- 统一输出到
./bin/app：go build -o ./bin/app -ldflags="-s -w" ./cmd/main.go - 交叉编译必须显式设平台：
GOOS=linux GOARCH=amd64 go build -o ./bin/app-linux-amd64 ... - Dockerfile 里用
COPY ./bin/app /app，而不是COPY . /app—— 减少攻击面、加速构建
GitHub Actions 中 GOPROXY 和 GOCACHE 不设等于白配
默认 GOPROXY=https://proxy.golang.org,direct，国内直连基本超时；不设 GOCACHE，每次都要重编标准库，单次构建多耗 30 秒以上。
- 在 workflow steps 里提前设置：
go env -w GOPROXY=https://goproxy.cn,direct -
go env -w GOCACHE=/tmp/gocache，再配合actions/cache@v3缓存~/go/pkg/mod和/tmp/gocache - 别依赖基础镜像自带的 GOPROXY——
golang:1.21和golang:alpine默认值可能不同
Docker 多阶段构建必须分离 build 和 runtime 阶段
用 golang:1.21 镜像直接跑生产服务？内存占用高、攻击面大、还带调试工具。真正轻量安全的做法是：build 阶段编译，runtime 阶段只放二进制。
- 第一阶段用
golang:1.21编译：go build -o /app/bin/app -ldflags="-s -w" ./cmd/main.go - 第二阶段用
gcr.io/distroless/static-debian12或alpine:latest，只COPY --from=0 /app/bin/app /app - 避免在最终镜像里留
go、git、sh—— distroless 镜像连 shell 都没有，更难被利用
最常被跳过的细节是：CI 里跑的 go test -race 和本地结果不一致，往往因为没设 GOMAXPROCS=2 强制触发竞态；还有人把 coverage.txt 生成逻辑漏掉，导致 Codecov 解析失败——覆盖率不是数字，是必须导出的文件。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
