测试覆盖率低不等于代码质量差，关键在于未覆盖的条件分支（如if err!=nil、缺失default的switch）可能隐藏逻辑缺陷；应通过依赖抽象、构造非nil error、避免log.Fatal等方式暴露并验证这些分支。
为什么测试覆盖率低不等于代码质量差
测试覆盖率低本身不是问题，问题在于你没意识到哪些分支路径根本没被触发。Go 的 go test -cover 统计的是语句执行率，但真正危险的是未覆盖的条件分支——比如 if err != nil 里那个永远走不到的 return，或者 switch 中漏掉的 default 分支。
常见导致分支未覆盖的写法
这些代码在本地跑得通，但测试很难打到所有分支：
-
os.Open返回的err在测试中常被 mock 成nil，导致if err != nil块完全不执行 - 函数内部调用
time.Now()或rand.Intn()，测试时无法控制返回值，某些分支天然不可达 - 使用
log.Fatal或os.Exit(1)的分支，一旦触发就终止进程，单元测试无法继续运行，该路径在覆盖率报告中显示为“未执行”，但你甚至没法写断言验证它 - switch 语句没有
default，而测试只覆盖了几个 case，其余枚举值或未知输入对应的分支静默丢失
如何让隐藏分支暴露出来
不是为了凑覆盖率数字，而是为了确认逻辑是否真能应对边界情况：
- 把外部依赖（如时间、随机数、文件系统）抽成接口或函数变量，测试时注入可控实现。例如把
func() time.Time作为参数传入，而不是直接调用time.Now() - 对 error 路径，不要只测
nil，要显式构造非 nil error：用fmt.Errorf("mock error")或io.EOF触发不同分支 - 如果用了
log.Fatal，考虑改用返回 error，让调用方决定是否退出；否则至少加一个testing.T.Setenv+ 环境开关，在测试时跳过 exit 行为 - 用
go tool cover -func查看具体哪个函数哪行没覆盖，再结合go tool cover -html定位到某个if的 else 块或某个case分支
覆盖率工具本身的陷阱
go test -cover 默认统计的是语句覆盖率（statement coverage），它不检查条件组合（如 a && b 中 a 为 true/b 为 false 是否单独覆盖），也不检查分支出口是否都被走到。这意味着：
立即学习“go语言免费学习笔记（深入）”；
- 一个
if x > 0 { A() } else { B() }，即使只测了x > 0，覆盖率仍可能显示 100%（因为两行语句都“出现”了，但 else 块没执行） -
for循环体只执行一次，和执行十次，在语句覆盖率里没区别；但边界条件（空切片、单元素、超长切片）可能引发不同逻辑分支 - panic 路径不会被计入覆盖率，但 panic 也是合法控制流——如果你的函数文档写着 “当输入为空时 panic”，那这个 panic 就该有对应测试，哪怕它不提升数字
真正值得盯住的，是 go tool cover -func 输出里标红的那些 if、else、case 和 default ——它们不是“没写代码”，而是“没验证过会不会出错”。
