通过 go test -coverpkg 可让独立于被测包的集成测试（如 http 端到端测试）精准统计目标业务包的实际代码覆盖率，解决常规 -cover 因测试文件不在同一包内而返回 0% 的问题。
在 Go 中进行 REST API 集成测试时，常见做法是启动服务进程、发送真实 HTTP 请求并验证响应——这类测试通常位于 main_test.go 或独立的 e2e/ 目录下，且属于 package main 或其他非业务包。此时直接运行 go test -cover ./... 仅统计测试文件所在包的覆盖率，而不会追踪其对 mypackage（含路由处理、业务逻辑、数据访问等核心代码）的执行路径，因此常显示为 0% 或极低值，严重失真。
正确方案是使用 -coverpkg 标志显式指定需覆盖分析的目标包。它会强制编译器将指定包（及其依赖的内部包）以插桩模式构建，并记录所有经由测试调用所触发的语句执行情况：
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
# 测量 mypackage 的实际覆盖率（即使测试在 main 包中） go test -cover -coverpkg=mypackage ./... # 若需覆盖多个包，用逗号分隔 go test -cover -coverpkg=mypackage,mydb,myauth ./... # 生成 HTML 覆盖率报告，便于逐行分析 go test -cover -coverpkg=mypackage -coverprofile=coverage.out ./... go tool cover -html=coverage.out -o coverage.html
✅ 关键说明：-coverpkg 的参数是导入路径（如 github.com/yourorg/yourapp/mypackage），而非文件路径；若包位于模块根目录下，可直接用相对包名（如 mypackage），前提是 go.mod 已正确声明模块路径且当前工作目录在模块内。
此外，为确保覆盖率数据真实反映集成场景：
-
避免重复测试干扰：-coverpkg 会同时运行被测包自身的单元测试（若存在）。若只想评估集成测试贡献的覆盖率，建议将单元测试与集成测试分离执行，或使用 -run 过滤：
go test -cover -coverpkg=mypackage -run=^TestIntegration.* ./...
-
注意包依赖范围：-coverpkg 默认不递归覆盖间接依赖。若业务逻辑深度调用 utils 或 models 包，需一并列入：
go test -cover -coverpkg=mypackage,utils,models ./...
最后需要强调：集成测试覆盖率 ≠ 单元测试覆盖率，前者更关注端到端路径连通性与错误分支触达能力，数值通常低于后者（30–60% 是合理区间）。高覆盖率不等于高质量，但持续追踪 mypackage 在真实请求流中的覆盖缺口（如未测试的 400/500 错误路径、边界参数组合），能有效识别防御性编码盲区。建议将 -coverpkg 命令纳入 CI 流程，并设定最低覆盖率阈值（如 --covermode=count --coverpkg=mypackage | grep -q "coverage: [6-9][0-9]\|100%"），推动关键业务包的测试完备性演进。
