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 上。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 加 -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 错一点，就等于没缓存。

• 缓存路径必须是 ${{ 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 逻辑不一致——这不是“差不多就行”的事，是“差一点就全崩”的事。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！