通过 go test -coverpkg 可以跨包统计集成测试对目标业务包的实际覆盖率，解决外部 http 测试无法反映真实逻辑覆盖的问题。
在 Go 项目中，尤其是构建 REST API 时，常采用“端到端式”集成测试：启动服务进程，通过 HTTP 客户端（如 net/http/httptest 或真实 http.Client）发送请求，验证响应状态、JSON 结构与错误处理逻辑。这类测试通常位于独立的测试包（如 main_test.go，属于 package main），不与被测业务逻辑同包——因此直接运行 go test -cover ./... 仅统计当前包内单元测试的覆盖，对核心 handler、service、repository 等包几乎无覆盖，导致报告为 0% 或极低值，严重失真。
真正的解决方案是使用 -coverpkg 标志，显式指定需纳入覆盖率统计的目标包（或包路径通配符）。它会强制编译器将指定包以“带覆盖率 instrumentation”的模式构建，并让外部测试在执行时收集其语句执行轨迹。
✅ 正确用法示例：
# 统计 integration 测试对 mypackage 的实际覆盖（推荐） go test -cover -covermode=count -coverpkg=./src/mypackage ./src/api/... # 若 mypackage 位于 module 根目录下，也可简写为： go test -cover -coverpkg=mypackage ./... # 支持多包，用逗号分隔： go test -cover -coverpkg=mypackage,utils,models ./...
⚠️ 注意事项：
- -coverpkg 必须与测试命令作用的包路径一致：若测试文件在 ./integration/ 目录下，需确保该目录下有 *_test.go 文件且能 import 并调用目标包；否则编译器无法关联 instrumentation。
- 推荐搭配 -covermode=count（而非默认 set），可生成更精细的行频次数据，便于后续用 go tool cover -func 或 HTML 报告定位未覆盖分支。
- 避免在 main 包中写大量业务逻辑：main 包应仅负责初始化与启动，核心逻辑务必下沉至可测试、可覆盖的独立包（如 handler/, service/, domain/）。
- 对于真实 HTTP 集成测试（非 httptest.NewServer），需确保测试进程能访问正在运行的服务，并注意端口冲突、超时、资源清理等问题——这些不影响覆盖率采集，但影响测试稳定性。
? 进阶建议：
将集成测试组织为标准 Go 测试包（如 integration/），并在 CI 中单独运行覆盖率分析：
# 生成详细 HTML 报告 go test -cover -covermode=count -coverpkg=./mypackage -coverprofile=coverage-integration.out ./integration/... go tool cover -html=coverage-integration.out -o coverage-integration.html
最终，-coverpkg 不是“取巧”，而是 Go 官方支持的、面向真实工程场景的覆盖率测量机制。它让集成测试的价值真正可度量——不再只看“是否跑通”，而是清晰看到“哪些 handler 分支、错误路径、边界条件尚未被 HTTP 请求触发”，从而驱动高质量、高覆盖的 API 测试体系建设。
