Go coverprofile 看不到子包覆盖率时怎么指定包范围

如果 go test -coverprofile=cover.out ./... 生成的报告里看不到被调用的子包，通常不是 cover.out 坏了，而是把“运行哪些测试”和“给哪些包插桩”混成了一件事。最小修正是：

# 运行模块内所有可匹配的测试，并给 ./... 范围内的包统一插桩
go test -count=1 -coverpkg=./... -coverprofile=cover.out ./...

./... 放在命令末尾表示测试包范围，-coverpkg=./... 才是覆盖率统计的包范围。生成后再用 go tool cover -func=cover.out 看函数明细，必要时用 go tool cover -html=cover.out -o coverage.html 导出页面。

只写 -coverprofile 不会自动把所有子包纳入统计；把测试目标和 -coverpkg 都写清楚，子包的文件才会出现在同一份报告里。

先分清两个“包范围”

Go 的测试命令有两个相互配合、但职责不同的范围。命令行最后的包列表决定哪些包要编译和运行测试；-coverpkg 决定每个测试程序对哪些导入路径匹配的包做覆盖率分析。官方 go test 文档说明，-coverpkg 未指定时，默认只分析正在测试的包。

例如目录可能是这样：

example.com/demo
├── service
│   ├── service.go
│   └── service_test.go
└── internal/format
    ├── format.go
    └── format_test.go

只在 service 包里执行测试时，默认报告主要反映 service 自己的语句。即使 service 调用了 internal/format，后者也不等于自动进入当前测试的覆盖统计范围。

用 -coverpkg=./... 收集子包覆盖率

在模块根目录执行下面的命令，适合先做一次完整基线：

# -count=1 关闭这次运行的测试缓存影响，便于确认报告确实重新生成
# -coverpkg=./... 给模块内匹配到的包做覆盖率插桩
# -coverprofile 把结果写到模块根目录的 cover.out
go test -count=1 -coverpkg=./... -coverprofile=cover.out ./...

这里两个 ./... 看起来相同，含义却不同：最后一个是“测试哪些包”，参数里的一个是“覆盖哪些包”。Go 官方测试脚本也专门覆盖了 go test -coverpkg=./... ./... 的场景，其中没有测试文件的包仍会进入整体覆盖率统计，只是显示为零覆盖或没有可执行语句。

如果只想关注模块中的两个包，可以把范围收紧：

# 只统计 service 和 internal/format，避免把示例目录或工具包混进来
go test -count=1 \
  -coverpkg=example.com/demo/service,example.com/demo/internal/format \
  -coverprofile=cover.out \
  ./service ./internal/format

先看函数报告，再决定是否打开 HTML

覆盖率数字适合看趋势，函数明细更适合排查“子包到底有没有进来”。

# 按函数打印每个文件的覆盖率，最后一行是总计
go tool cover -func=cover.out

在输出中搜索子包导入路径。如果 internal/format/format.go 出现，说明它已经被纳入 profile；如果函数仍是 0.0%，说明包被统计了，但这次测试没有走到对应分支。两种情况不要混为“没有收集”。

# 生成不依赖浏览器的 HTML 文件，便于 CI 归档或本地打开
go tool cover -html=cover.out -o coverage.html

官方 cmd/cover 提供了 -func 和 -html 两种读取方式。它们都只消费已有 profile，不会替你扩大收集范围；如果报告里没有子包路径，应该回头检查 -coverpkg，而不是先改报告命令。

四个容易让结果看起来“不对”的点

一是工作目录。./... 以当前模块上下文解释。脚本如果从子目录启动，匹配到的包可能和本地手工执行不同，CI 最好明确在模块根目录运行，或者写完整导入路径。

二是测试缓存。覆盖率相关参数属于可缓存参数的一部分，重复运行可能看到缓存提示。排查报告是否真的更新时加上 -count=1，不要用删除整个缓存目录来代替判断。

三是没有测试文件。被 -coverpkg 匹配到的包不一定有自己的 _test.go。它可以因为被其他测试包调用而产生数据，也可能保持零覆盖；“没有测试文件”和“没有进入覆盖范围”是两回事。

四是覆盖模式。默认模式通常是 set；启用 -race 时默认会使用更适合并发计数的 atomic，代价也更高。除非确实需要，不要为了让百分比变高而随意改模式。

把命令固定进 CI

CI 中建议固定模块根目录、报告文件名和包范围，并把报告生成与测试命令分开：

# 在模块根目录执行；先产出统一 profile
set -eu
mkdir -p artifacts
go test -count=1 -coverpkg=./... -coverprofile=artifacts/cover.out ./...

# 再产出可归档的函数统计和 HTML
go tool cover -func=artifacts/cover.out > artifacts/coverage.txt
go tool cover -html=artifacts/cover.out -o artifacts/coverage.html

实际脚本里应先创建 artifacts，再把报告作为 CI 工件上传。这样排查时能回答三个问题：测试跑了哪些包、profile 包含哪些包、低覆盖率具体落在哪些函数。

相关问题

为什么子包在报告里是 0.0%？通常是它已被 -coverpkg 纳入，但当前测试没有执行其中的语句；先看函数明细，再补针对真实行为的测试。

只想测当前包，还要写 -coverpkg 吗？不需要。默认包范围适合快速看当前包；只有要把依赖包、多个业务包或整个模块放到同一统计口径时才显式指定。

coverprofile 能直接打开吗？它是给工具读取的文本 profile，使用 go tool cover -func 或 -html 转成可读报告，不要把它当成 HTML 文件。

参考：go command 官方文档、Go 官方 coverpkg 测试脚本、cmd/cover 官方源码说明。