低覆盖率主因是未覆盖错误返回、边界输入、并发分支和私有逻辑；需构造失败场景、完善表驱动测试、显式验证并发与初始化副作用，并在CI中设置覆盖率门禁。
go test -cover 显示覆盖率低，不是数字问题，而是测试没打中关键路径。90% 的低覆盖率都集中在错误返回、边界输入、并发分支和私有逻辑上——这些地方不写针对性用例，光跑主流程永远卡在 60–70%。
为什么 if err != nil 总是红色？
因为你的测试没真正触发错误。比如调用 os.Open、json.Unmarshal 或自定义的校验函数时，只测了“成功”，没构造失败场景。
- 对文件操作：传入不存在路径或无权限路径，而非仅用
tempfile - 对 JSON 解析：用非法字符串（如
"{key: value}"缺少引号）、超长嵌套、空字节流 - 对业务校验函数：传
nil、空字符串、负数 ID、超长 slice —— 不要只测“看起来合理”的值
别依赖真实环境抛错；用接口抽象 + mock（如 io.Reader 替换为 bytes.NewReader(nil)）更稳定、更快。
表驱动测试没覆盖全分支？
table-driven tests 是 Go 最推荐的方式，但很多人只列了 2–3 个 case，漏掉关键组合。尤其当函数含多个 if 嵌套或 switch 分支时，单靠直觉容易遗漏。
- 把每个
if条件单独拎出来设计输入：比如if len(s) == 0、if s[0] == '{'、if !utf8.ValidString(s)应各自有对应测试项 - 用
t.Run命名明确表达意图，如"empty_string_returns_error"而非"case1" - 对返回 error 的函数，不仅要
assert.Error，还要assert.Contains(err.Error(), "xxx")，确保走的是预期分支
func TestParseConfig(t *testing.T) {
tests := []struct {
name string
input string
wantErr bool
}{
{"empty", "", true},
{"invalid_json", "{key: value}", true},
{"valid", `{"timeout": 5}`, false},
{"utf8_invalid", "\xff\xfe\xfd", true},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
_, err := ParseConfig(strings.NewReader(tt.input))
if (err != nil) != tt.wantErr {
t.Errorf("ParseConfig() error = %v, wantErr %v", err, tt.wantErr)
}
})
}
}
并发代码和初始化逻辑为什么总不覆盖？
并发路径（如 go func() { ... }()）、init() 函数、包级变量赋值、http.HandlerFunc 中的中间件链，天然难触发。它们往往在覆盖率报告里整块变红，但没人专门去碰。
- 对 goroutine：用
sync.WaitGroup+time.After或 channel 等待其完成，再断言结果 - 对
init()：无法直接调用，但可测试其副作用——比如是否注册了某 handler、是否设置了某全局 flag - 对 HTTP handler：不要只测路由分发，要 mock
http.ResponseWriter和构造*http.Request，覆盖 status code、header、body 写入逻辑
特别注意：go test -cover 默认不统计未执行的 goroutine 内部语句，必须确保测试能实际进入并退出该 goroutine。
CI 里加了 -cover 但还是倒退？
因为只生成报告，没设门禁。覆盖率下降没人知道，直到上线出问题。
- 在 CI 脚本里加检查：用
go tool cover -func=coverage.out | grep "total:"提取数值，对比基线 - 拒绝低于阈值的提交（如
if $(awk '/total:/ {print $3}' coverage.txt | sed 's/%//') -lt 85; then exit 1; fi） - 避免用
-covermode=count做门禁——它统计执行次数，容易被循环刷高，失真；用默认的atomic或set模式更准
最常被忽略的一点：覆盖率工具不会告诉你「哪行该测但没测」，只会标红。真正要提升质量，得打开 coverage.html，点进每个红块，问自己：“这段逻辑在什么情况下会执行？我有没有让它执行过？”——答案就是下一个测试用例。
