Go testing覆盖率只看包内代码时的统计边界

Go 项目里最容易误读的一项指标就是覆盖率：测试明明调用了内部包，报告却只出现当前包的文件。这个结果通常不是 testing 丢数据，而是 go test -cover 的默认边界所致。默认模式只对命令行指定的测试目标包做覆盖率插桩；要把同一模块里的其他包纳入统计，需要明确写出 -coverpkg。

默认 -cover 为什么只看到当前包

假设模块有 internal/service、internal/repository 两个包，测试入口放在 service。执行 go test -cover ./internal/service 时，Go 会为 service 的测试建立覆盖率统计，repository 虽然被调用，默认也不会自动成为统计对象。

这里要分清两个动作：一是测试代码实际执行了哪些函数，二是哪些包被插桩并写入 profile。没有被插桩的包，即使被调用，也不会出现在这份覆盖率报告里。

先用 coverprofile 建立单包基线

先保留一份最小基线，便于和扩大范围后的结果比较：

# 生成 service 包自己的覆盖率报告，便于复查统计口径
go test -coverprofile=cover-service.out ./internal/service

# 只查看摘要，不把百分比当成跨包总覆盖率
go tool cover -func=cover-service.out

-coverprofile 会把覆盖率数据写入文件，go tool cover -func 再按函数或文件汇总。基线的价值不在于数字一定高，而在于它的包集合稳定、容易定位差异。

用 -coverpkg 把依赖包纳入同一份报告

如果质量门禁要回答“service 的测试对内部实现覆盖了多少”，就明确指定包路径：

# 将同一模块的包作为覆盖率插桩候选，并只运行 service 测试
go test -coverpkg=./internal/... -coverprofile=cover-module.out ./internal/service

# 查看扩展报告中的文件和函数覆盖情况
go tool cover -func=cover-module.out

-coverpkg 控制被分析的包集合，最后的 ./internal/service 仍然是本次运行的测试目标。也就是说，这条命令不会替你单独运行 repository 的测试；如果 service 的测试没有走到 repository 的某个分支，那些语句仍会保持未覆盖。

按目标选择统计口径

排查时先打开 profile 看文件路径，再判断测试是否覆盖了对应函数。不要只比较一行百分比：扩大插桩范围后，分母变大，数字下降可能只是统计对象增加。

相关问题

为什么加了 -coverpkg 后覆盖率反而下降

因为报告纳入了更多包，未执行的语句也进入分母。先确认新增包是否属于质量门禁目标，再补测试或收窄匹配范围。

-coverpkg=./... 会自动运行所有包的测试吗

不会。它描述覆盖率插桩范围，测试目标仍由命令末尾的包参数决定；要运行多包测试，需要明确使用相应的包列表命令。

什么时候应该坚持单包覆盖率

当团队要衡量某个包的局部回归质量，单包口径更容易稳定比较；跨包指标应另设命令和阈值，不要混在同一条基线里。