Go项目CI/CD失败主因是环境不一致、依赖未锁死或产物路径失控；须提交go.sum、执行go mod tidy、禁用GOSUMDB=off、显式设GOPROXY/GOCACHE、硬编码build输出与ldflags、导出coverage.txt并校验阈值。
Go 项目在 CI/CD 流水线里失败，八成不是 Go 本身的问题，而是构建环境没对齐、依赖没锁死、或产物路径没管住——本地 go build 能跑，CI 里就报 undefined: http.HandleFunc 或 module lookup failed，这类问题几乎都出在初始化阶段。
go mod tidy 和 go.sum 必须一起提交
CI 环境默认是空缓存、无 GOPATH、无本地模块副本的干净容器。不提交 go.sum，go build 会重新解析依赖树，可能拉到带漏洞或行为变更的次版本；不运行 go mod tidy，则 go.mod 里可能残留已删除代码引用的模块，导致构建时 panic。
- 每次 PR 提交前，必须执行
go mod tidy -v并检查输出是否新增/删减了模块 -
go.sum文件不能忽略、不能 gitignore、不能只在本地保留 - 禁止在 CI 中加
GOSUMDB=off—— 它绕过校验，等于主动放弃供应链安全底线
GitHub Actions / GitLab CI 中必须显式设置 GOPROXY 和 GOCACHE
默认 GOPROXY 是 https://proxy.golang.org,direct，国内直连大概率超时；GOCACHE 不设路径会导致每次构建都重编译标准库，浪费 30 秒以上。
- GitHub Actions 推荐写法：
go env -w GOPROXY=https://goproxy.cn,direct+go env -w GOCACHE=/tmp/gocache - GitLab CI 建议在
.gitlab-ci.yml全局variables里定义：GOCACHE: "$CI_PROJECT_DIR/.gocache"，再用cache:持久化该路径 - 不要依赖镜像自带的 GOPROXY 设置——不同基础镜像（如
golang:1.21vsgolang:alpine）默认值可能不同
go build 输出路径和链接参数必须硬编码
不指定 -o，go build 默认把二进制丢到当前目录，CI 后续步骤无法定位；不用 -ldflags，二进制会带上调试符号，体积翻倍且暴露内部路径。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 统一用
go build -o ./bin/myapp -ldflags="-s -w" ./cmd/myapp -
./bin/是约定俗成的产物目录，方便后续 Docker COPY 或部署脚本直接引用 - 交叉编译时务必加
GOOS/GOARCH，例如GOOS=linux GOARCH=arm64 go build -o ./bin/myapp-linux-arm64 ...；否则默认按宿主机平台编译，CI 容器里跑的是 Linux，你本地是 macOS，产物根本没法用
测试覆盖率要导出文件并校验阈值
go test 默认不生成可读报告，CI 工具（如 Codecov、GitLab CI 的 coverage regex）全靠解析 stdout 或特定文件。不生成 coverage.txt，覆盖率就只是个数字，没法卡门禁。
- 必须加
-coverprofile=coverage.txt -covermode=count，原子模式（atomic）在并发测试中更准，但部分 CI 工具不兼容，优先用count - 用 shell 提取数值：
grep 'coverage:' coverage.txt | awk '{print $2}' | sed 's/%//' | awk '{if ($1 - 别信
go test -cover控制台输出的百分比——它只统计当前包，不包含子包，容易虚高
最容易被跳过的其实是资源绑定和 CGO：用了 embed.FS 却没在 CI 中启用 Go 1.16+；开了 cgo 却没装 gcc 或 ca-certificates，导致 HTTPS 请求失败。这些不是“偶尔出错”，而是每次换环境必现。
