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 只记录是否执行过（布尔值），在并发测试中避免竞态，但丢失频次信息，对调试帮助小。
立即学习“go语言免费学习笔记（深入）”；
- 使用
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 场景或并发交互——工具只告诉你“代码动了”，没告诉你“动得对不对”。
