覆盖率不指导重构但能暴露未测逻辑，需用-go tool cover -func或-html查函数级明细，-covermode=count识别伪覆盖，-coverpkg=./确保全模块覆盖。
覆盖率本身不指导重构，但它能精准暴露“哪些逻辑被测试绕过了”——这才是重构前必须看清的起点。
为什么 go test -cover 不能直接指导重构
它只告诉你“65.2% of statements”，但不说明：哪几个函数长期靠手动调用、哪段 error 分支从没进过、哪个 if 的 else 块被当成死代码忽略。这种笼统数字容易让人误判“差不多够了”，结果一动就崩。
真正有用的是 go tool cover -func=coverage.out 输出的函数级明细，或 go tool cover -html=coverage.out 中标红的具体行。
- 红色行往往对应未测的错误路径（如
if err != nil { return } else { ... }只覆盖了else） - 灰色行不是问题，但若某个函数全灰（只有签名、空结构体），说明它根本没被调用，可能已成僵尸代码
- 某函数覆盖率 90% 但关键分支（如数据库超时处理）是红的，比一个 40% 覆盖率但所有分支都绿的函数更危险
-covermode=count 比 set 更适合识别重构缺口
set 模式只记录“执行过/没执行过”，而 count 记录每行执行次数——这对发现“伪覆盖”特别关键。
立即学习“go语言免费学习笔记（深入）”；
比如一个 HTTP handler 里有：
if req.Header.Get("X-Auth") == "" {
http.Error(w, "unauthorized", 401)
return
}
// 处理业务逻辑...
如果所有测试都带了 X-Auth，那第一块 if 分支永远不触发，set 模式只会标红；但 count 能让你一眼看出该分支计数为 0，且 http.Error 行在 HTML 报告里是纯红——这就是明确的重构信号：补一个无 auth 的测试，或确认该分支是否真可删。
- 本地调试优先用
-covermode=count，速度快、数据直观 - CI 环境涉及并发（如启动
http.Server后发请求）必须换-covermode=atomic，否则计数不准 - 别和
-race同时用：cannot use -race and -covermode=atomic together
重构前先跑 go test -coverpkg=./ ./ 看真实覆盖范围
很多模块看似有单元测试，但 go test -cover 在子包目录下跑，只统计当前包——handler 调用的 service、repository 完全不在视野里。重构时若只盯着“本包 80% 覆盖率”，可能把一堆未覆盖的下游逻辑当安全区动了。
必须在 go.mod 根目录执行：
go test -v -covermode=count -coverprofile=coverage.out -coverpkg=./ ./
-
-coverpkg=./强制为整个模块所有子包（含internal/、pkg/）插桩，确保 handler→service→db 链路全在统计中 - 末尾的
./不能省，否则只跑根目录测试，internal/handler等包被跳过 - 跑完立刻检查
coverage.out文件大小：若 _test.go 命名和TestXXX函数规范
重构后验证：别只看百分比，盯住关键函数的红行是否消失
重构完成后的验证，重点不是“覆盖率涨到 92%”，而是原先标红的关键路径是否变绿。
例如你把一个大函数拆成 validateInput、fetchData、buildResponse 三个小函数：
- 运行
go tool cover -func=coverage.out | grep -E "(validateInput|fetchData|buildResponse)"，确认每个函数覆盖率 ≥85% - 打开
go tool cover -html=coverage.out，重点检查原函数里标红的else、default、return err是否在新函数中被绿色覆盖 - 如果某个新函数仍全红，说明测试没调用它——可能是依赖注入没配对，或 mock 没打到正确接口
最常被忽略的是：重构后测试仍用旧路径调用，新函数实际没被执行。覆盖率报告不会说“你改了但没测”，它只会沉默地显示那几行还是红的。
