Go单元测试覆盖率卡在70–85%主因是未覆盖error分支、defer、context取消路径及else块；需用go tool cover -func定位0.0%/33.3%/50.0%函数，显式构造错误、区分nil/空切片、表格驱动测试context分支，并拆解函数+注入依赖提升可测性。
Go 框架下单元测试覆盖率卡在 70–85% 是常态，真正拉低数字的不是主干逻辑，而是 if err != nil 分支、defer 清理块、context 取消路径和未触发的 else 块——这些地方不补上，覆盖率再高也挡不住线上 panic。
用 go tool cover -func 定位真实盲区
别只信 go test -cover 输出的总百分比。执行 go test -coverprofile=coverage.out 后，立刻跑：
go tool cover -func=coverage.out
重点关注 coverage 值为 0.0%、33.3% 或 50.0% 的函数，它们通常意味着：
-
if err != nil分支一次没进过，因为 mock 总返回nil -
else块写在if len(s) == 0后，但测试只传了非空切片 -
defer里的close()或日志因提前return没执行 - 带
context.Context的函数，测试没传已cancel()的 ctx，取消路径静默失效
显式构造 error 分支，拒绝“自然失败”
Go 的错误处理是显式的，但多数测试只走成功路径。真实服务里，db.QueryRow 失败、http.Do 超时、json.Unmarshal 解析空 body —— 这些必须手动造出来，不能指望“运气”。
立即学习“go语言免费学习笔记（深入）”；
- 用
testify/mock或gomock时，对同一方法至少定义两条行为：mock.On("Get").Return(user, nil)和mock.On("Get").Return(nil, errors.New("timeout")) - HTTP handler 测试中，用
httptest.NewRequest("POST", "/api", nil)触发 body 读取失败；用bytes.NewReader([]byte(""))模拟空 JSON - 注意
nil切片和空切片的区别：var s []string = nil与s := []string{}在len(s) == 0后可能触发不同分支，都要覆盖
表格驱动 + context 控制，精准命中取消/超时分支
别在测试里写 time.Sleep(1 * time.Second) 等超时，既慢又不可靠。把 context 构造也纳入表格驱动：
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},
{"timedout", context.WithTimeout(context.Background(), 1*time.Nanosecond), true},
}循环执行时，每个 case 都能独立验证 ctx.Err() 是否被正确检查和返回。
拆函数 + 注入依赖，让 defer 和边界逻辑可测
一个函数如果混着业务逻辑、defer 清理、context 检查和错误包装，几乎不可能全覆盖。拆解后才能逐块验证：
- 把 DB 查询、HTTP 调用、文件读写等外部调用抽成接口，测试时注入可控实现（比如返回
io.EOF或自定义 error） - 将
defer中的关键逻辑（如资源释放、状态回滚）提取为独立函数，直接测试其输入输出 - 避免在函数内硬编码
time.Now()或rand.Intn()，改为通过参数或接口传入，否则无法稳定复现边界时间点或随机值
覆盖率报告里那些红色行，往往不是“没写测试”，而是“代码本身没法测”——这时候重构比补测试更有效。
