Go test -cover 忽略了未执行的分支，不是 bug 是设计
go test -cover 默认只统计「被运行到的代码行」的覆盖率，根本不会告诉你哪些 if 分支、switch case 或 else 块压根没进过。它报告的是「行覆盖（statement coverage）」，不是「分支覆盖（branch coverage）」。这意味着：一个 if err != nil { return } else { doWork() }，哪怕你只测了 err == nil 的路径，-cover 仍可能显示 100%——因为两行都“被执行”了（else 那行语法上存在，就算没进也计数）。
-
go test -cover不区分if和else是否真实执行，只看 Go 编译器生成的语句块是否被命中 - 真正的分支遗漏（比如永远走不到的
case "unknown":）在默认覆盖率里完全隐身 - 想暴露这类问题，必须用
go test -covermode=count -coverprofile=cover.out配合go tool cover查看具体每行执行次数，再人工比对逻辑分支
用 gotestsum + coverprofile 分析分支执行次数
单纯靠 go test -cover 数字会误判；要定位「哪个 if 分支漏测」，得看每行实际执行了多少次。常见做法是导出详细计数 profile，再用工具展开：
- 运行
go test -covermode=count -coverprofile=cover.out ./... - 执行
go tool cover -func=cover.out查看函数级调用次数 - 更关键的是
go tool cover -html=cover.out -o=cover.html，打开 HTML 报告后，灰色背景 = 0 次执行，黄色 = 1 次，绿色 = 多次——重点盯住if后面那行、else块首行、case标签行的颜色
注意：-covermode=count 会略微拖慢测试速度，CI 中建议只在需要深挖时启用，日常用 -covermode=atomic 即可。
goroutines 和 defer 在覆盖率中「消失」的真相
协程启动后立刻返回、defer 函数延迟执行——这两类代码在 go test 默认流程中极易被漏统计：
立即学习“go语言免费学习笔记（深入）”；
go doAsync()启动的 goroutine 若没显式同步（如sync.WaitGroup或time.Sleep），测试函数退出时它可能还没跑完，对应代码行直接记为「未执行」defer语句本身那行会被计入，但被 defer 的函数体，如果因 panic 或提前 return 未触发，就永远不会出现在 profile 里测试含 goroutine 的逻辑，必须确保主测试函数等待其完成，不能依赖「它应该很快」
对 defer 内部逻辑做覆盖验证，得构造让它必然执行的场景（比如避免在 defer 前 panic）
使用
runtime.Gosched()强制调度不能替代真实等待，它不保证 goroutine 已执行完毕
第三方库 mock 不影响覆盖率，但会掩盖真实分支
用 gomock、testify/mock 替换依赖时，容易忽略一个事实：mock 返回值是硬编码的，它让某条错误路径「看起来」被覆盖了，其实只是绕过了原始逻辑。
比如被测函数调用
db.QueryRow()，你 mock 成始终返回nilerror，那么所有if err != nil分支永远不进，但覆盖率数字照样涨——因为 mock 实现本身被运行了更隐蔽的是：mock 的
Return()链式调用若写错（如少一个参数），会导致 panic，但 panic 发生在 mock 框架内部，你的业务else块依然没被测到覆盖率数字上升 ≠ 逻辑分支被验证，尤其当 mock 掩盖了 error flow 时
关键分支（如网络超时、数据库约束失败）建议用集成测试+真实依赖轻量实例（如 sqlite 内存 DB、httptest.Server）补足
如果坚持用 mock，请为每个 error case 单独写测试，且 assert mock 的
Times()是否匹配预期调用次数
分支覆盖不是靠工具自动填满的数字，是靠你明确写出「这个 if 的 false 分支必须发生一次」的测试用例。否则，go test -cover 显示的 95%，很可能意味着还有 5 个关键 else 块从未被触发过。
