真正卡住覆盖率提升的是未触发的错误分支、else块、defer清理及context取消路径；需用go tool cover -func定位0.0%等盲区，显式构造error、表格驱动context测试、拆函数注入依赖，并以覆盖率暴露设计问题。
go test -cover 显示的百分比只是表象，真正卡住覆盖率提升的，是那些没被触发的 if err != nil、else、defer 清理逻辑，以及 context 取消后直接 return 的分支。数字高不等于安全，但 coverage: 0.0% 的函数几乎一定藏着线上 panic 风险。
用 go tool cover -func 定位真实盲区
别只盯着终端里那个总百分比。执行完 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 的错误处理是显式的，但多数测试只走 happy path。真实服务里，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
}{
{"success", context.Background(), false},
{"ctx cancelled", func() context.Context {
ctx, cancel := context.WithCancel(context.Background())
cancel()
return ctx
}(), true},
{"ctx timeout", context.WithTimeout(context.Background(), 1*time.Millisecond), true},
}这样能确保 select 中的 <-ctx.Done() 分支稳定触发，且不依赖系统调度延迟。
拆函数 + 接口注入，让不可控逻辑可测
直接调 time.Now()、rand.Intn() 或全局 db 实例，会让单元测试变成环境依赖型“集成测试”。真正可维护的做法是：
- 把时间/随机逻辑抽成函数变量：
var Now = time.Now，测试时替换为固定返回值 - 定义接口抽象外部依赖：
type DB interface { QueryRow(...)，函数签名接收该接口而非具体实现 - 测试中传入 mock 实例，并在结尾加
mock.AssertExpectations(t)，防止漏设期望还误以为通过
最常被忽略的一点：覆盖率工具插桩的是源码语句，但如果你的 log.Fatal 写在某个 if 分支里，而这个分支永远没被执行，go tool cover -html 会把它标红——可你根本没意识到这段代码本就不该存在，或者需要重构掉这个 panic 行为。覆盖率不是目标，而是暴露设计问题的镜子。
