真正要盯的是未执行的错误处理分支，如if err != nil、len(s) == 0、ctx.Err() != nil等，它们一旦跳过可能导致panic或数据错乱；应使用go tool cover -func定位0.0%或33.3%覆盖率的函数，显式mock error路径，表格驱动测试覆盖context取消/超时、空/nil切片等边界，并将log.Fatal移至main层，让错误作为值返回以便完整验证。
覆盖率数字高不等于业务逻辑被真正验证过，真正要盯的是那些没执行的 if err != nil、len(s) == 0、ctx.Err() != nil 分支——它们一旦跳过，线上就可能 panic 或数据错乱。
用 go tool cover -func 定位真实盲区
别只看 go test -cover 输出的总体百分比。那个数字会掩盖关键失衡：比如工具函数 100%，而核心 ProcessOrder 函数里数据库写失败后直接 log.Fatal 的三行永远红色。
- 先运行
go test -coverprofile=coverage.out ./生成数据 - 立刻执行
go tool cover -func=coverage.out，重点关注 coverage 值为0.0%或33.3%的函数——这些往往对应未触发的else、return err或defer清理逻辑 - 避免初期用
-covermode=count；默认set模式更快暴露“是否执行”，比“执行几次”更贴近测试意图
显式 mock error 分支，拒绝“自然失败”
业务函数里大量防御逻辑藏在 if err != nil 后面，但多数测试只传合法参数、连真实 DB 都跑通就收工，导致这些分支根本没进过。
- 对每个返回
error的依赖调用，mock 至少设两条路径：mock.On("CreateUser").Return(user, nil)和mock.On("CreateUser").Return(nil, errors.New("duplicate email")) - HTTP handler 测试中，用
httptest.NewRequest("POST", "/order", bytes.NewReader([]byte("")))强制触发 JSON 解析失败 - 注意
nil切片和空切片的区别：var s []string = nil与s := []string{}在len(s) == 0后可能触发不同分支，都要覆盖
表格驱动 + context 控制，精准命中取消/超时分支
别在测试里写 time.Sleep(1 * time.Second) 等超时，既慢又不可靠。把 context 构造也纳入表格驱动：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
tests := []struct {
name string
ctx context.Context
wantErr bool
}{
{"default", context.Background(), false},
{"cancelled", func() context.Context {
ctx, cancel := context.WithCancel(context.Background())
cancel()
return ctx
}(), true},
}- 构造已 cancel 的 ctx：
ctx, cancel := context.WithCancel(context.Background()); cancel(); return ctx - 或超短 timeout：
context.WithTimeout(context.Background(), 1*time.Millisecond) - 子测试名带上关键变量，如
"with_empty_items"或"ctx_cancelled"，便于快速定位漏测路径
拆解函数 + 错误返回替代 log.Fatal
log.Fatal 是终态行为，混入逻辑函数会直接终止测试进程，让错误路径无法验证。
- 将业务逻辑移出
main，错误作为值返回；log.Fatal只保留在main层统一处理 - 例如
readConfig(path string) (Config, error)不做任何日志或退出，只负责读取与解析，失败时返回error - 这样测试才能自由传入非法路径、损坏 JSON 等输入，完整覆盖所有分支
最常被忽略的是：灰色代码行（函数签名、注释、空行）不参与统计，不用补；而红色行才是真问题——尤其是 defer 里的资源清理、else 块、default 分支，它们不执行，线上就容易出 silent failure。
