go test -cover 统计被测试执行到的可执行语句行，如 if、for、return、函数调用等；不统计函数签名、注释、type/变量声明（无初始化）、import 等不可执行行。

go test -cover 能统计到哪些代码行

它只统计被 go test 执行到的源码文件中的可执行语句，不包括：函数签名、空行、注释、type 声明、变量声明（无初始化表达式）、import 语句。真正参与计算的是 if、for、函数调用、return、赋值表达式等有运行行为的行。

常见误解是认为覆盖率=“所有非空行被覆盖”，其实不是——Go 的覆盖率基于「插桩」（instrumentation），只有编译器能插入计数器的地方才算。比如：

func Add(a, b int) int {
    return a + b // 这一行会被统计
}
func PrintHello() {
    fmt.Println("hello") // 这一行也会被统计
}
var Version = "1.0" // 这一行不会被统计（纯声明）

如何生成 HTML 格式的覆盖率报告

关键命令是 go test -coverprofile=coverage.out 先生成 profile 文件，再用 go tool cover 渲染成 HTML。必须分两步，不能跳过中间文件。

• -coverprofile 必须指定一个 .out 后缀的文件名，否则 go tool cover 无法识别
• 如果项目含多个包，建议在项目根目录运行 go test ./...，并加 -covermode=count（推荐）以支持分支和重复执行计数
• HTML 报告中绿色=已执行，红色=未执行，灰色=不可测（如 default 分支在 switch 中无对应 case 时）

go test -covermode=count -coverprofile=coverage.out ./...
go tool cover -html=coverage.out -o coverage.html

为什么 -covermode=count 比 atomic 更实用

-covermode=count 记录每行被执行的次数，能暴露「看似覆盖、实则没走通逻辑分支」的问题；而 atomic 只记录是否执行过（布尔值），在并发测试中避免竞态，但丢失频次信息，对调试帮助小。

• 使用 count 模式后，HTML 报告里鼠标悬停能看到具体执行次数，比如 if err != nil 分支只跑了 1 次，但你预期它该在错误路径下也触发
• atomic 仅在 go test -race 同时启用时才必要，日常开发和 CI 推荐默认用 count
• set 模式（默认）最弱，只回答“有没有跑过”，不适合质量卡点

在 CI 中校验覆盖率阈值的可靠写法

别依赖 go test -cover 输出文本解析——不同 Go 版本输出格式可能微调，容易误判。应该用 go tool cover -func 提取结构化数据再判断。

• go tool cover -func=coverage.out 输出形如 foo.go:12.3,15.5 2（文件:起始行.列,结束行.列 执行次数），最后一列是计数
• 用 shell 提取总覆盖率百分比： go tool cover -func=coverage.out | tail -1 | awk '{print $3}' | sed 's/%//'
• 注意：该百分比是「所有被测文件的加权平均」，不是简单算术平均；若某大文件完全没测，会显著拉低结果

复杂点在于：覆盖率数字本身不反映测试质量。100% 覆盖的函数仍可能漏掉边界条件、panic 场景或并发交互——工具只告诉你“代码动了”，没告诉你“动得对不对”。