go test在CI中必须确保过得准、卡得牢、跑得稳：加-timeout=60s防挂起、-p=1禁并行、-v输出日志、-failfast快速失败，禁用os.Exit(1)/log.Fatal，用-covermode=count生成覆盖率并校验阈值。
CI/CD 流水线里跑 go test 不是“能不能过”的问题，而是“过没过准、卡没卡住、慢不慢”的问题——本地通过的测试，在 CI 上失败，90% 是环境、并发或退出码被忽略导致的。
为什么 go test 在 CI 中常静默成功
GitLab CI 和 GitHub Actions 默认只看命令返回码。而 go test 遇到 panic 或未调用 t.Fatal 的错误时，可能仍返回 0（成功），导致流水线误判为“测试通过”。
- 必须加
-failfast：一有失败立刻终止，避免后续测试掩盖真实问题 - 必须加
-v：否则日志里看不到具体哪个子测试 panic 了 - 推荐加
-race：竞态检测本身会强制非零退出码，且能暴露 goroutine 级 bug - 别用
go test ./cmd这类窄路径：漏掉./internal或./pkg下的核心逻辑，应统一用./（当前模块内所有可测试包）
go test 必须配的超时与并行控制
CI 环境资源受限、DNS 慢、临时目录权限异常，容易让测试卡在 HTTP client 轮询、DB 连接或 time.Sleep 上。
- 加
-timeout=60s：防止单个测试挂起整个 job；超过即中断并返回非零码 - 调试阶段建议加
-p=1：禁用并行，排除共享状态干扰（比如多个测试共用一个全局 map） - 禁止在测试中调用
os.Exit(1)或log.Fatal：它们绕过t.Error收集机制，导致覆盖率统计中断、日志截断、退出码不可靠 - 所有外部服务（Redis、PostgreSQL）必须在 job 内启动，并用
net.DialTimeout或redis-cli ping显式健康检查，不能靠sleep 5
缓存 Go modules 的关键细节
每次拉 module 不仅慢，还可能因网络抖动失败。但缓存路径和 key 错一点，就等于没缓存。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 缓存路径必须是
${{ env.GOPATH }}/pkg/mod（Go 1.14+ module 模式默认写入位置） - key 必须基于
**/go.sum：用hashFiles('**/go.sum')，不是go.mod—— 间接依赖变更只体现在go.sum中 - fallback key 加一行
go-mod-${{ hashFiles('**/go.mod') }}：防止首次提交还没生成go.sum时完全跳过缓存 - 必须在
go test前执行go mod download：否则go test首次触发下载，可能超时或受 GOPROXY 波动影响
覆盖率报告要能拦截低质量提交
生成 coverage.out 不难，难的是让它真正卡住流程。
- 用
-covermode=count（不是atomic）：支持多包合并，函数级统计更准 - 聚合后必须校验阈值：比如
go tool cover -func=coverage.out | grep "total:" | grep -q "80.0%"，不达标就exit 1 - 注意
main包默认不被覆盖：若主程序逻辑重要，需显式在main_test.go中调用main()并测试其行为 - 别信
go test -cover终端输出的百分比：它只统计当前包，跨包调用路径可能被漏掉
最易被忽略的点：Go 版本必须显式锁定（如 v1.21.10），minor 版本差异可能导致 net/http timeout 行为突变，或 testing.T 的 cleanup 逻辑不一致——这不是“差不多就行”的事，是“差一点就全崩”的事。
