go test -v 输出里怎么看出实际执行的代码行数？
Go 的 go test 本身不统计「代码行数」，它只报告测试通过/失败、覆盖率（需额外开启）、以及每个测试函数的耗时。所谓“执行了多少行”，其实是误读——真正可量化的是「被测试覆盖的源码行数」，这依赖于 go test -cover 和底层的覆盖率分析机制。
实操建议：
- 运行
go test -coverprofile=coverage.out ./...生成覆盖率数据文件 - 用
go tool cover -func=coverage.out查看每个函数的语句覆盖率（注意：是「可执行语句」，不是物理行数；空行、注释、函数签名都不算） - 别把
cover的百分比当成「行数占比」，它统计的是 AST 中的可执行节点（如return、if分支、赋值语句），一行里多个语句可能被拆成多个节点
为什么 go tool cover 统计结果和编辑器显示的行数对不上？
因为 Go 覆盖率工具压根不按「文本行号」做最小单位，而是基于编译器生成的 SSA 中间表示，标记哪些「控制流节点」被执行过。这就导致几个常见错觉：
- 一个
for循环体里写了 5 行，但只执行了 1 次 → 工具可能标为「100% 覆盖该循环体」，哪怕你只跑了第一行里的赋值 - 带
fallthrough的switch分支，容易漏掉某个 case 的覆盖标记，看起来像“少算了一行”，其实是 fallthrough 改变了控制流路径 - 内联函数（
//go:noinline以外的短函数）会被展开，其语句混入调用处，行号映射会偏移
想精确知道某次测试跑过了哪些具体行，该用什么命令？
用 go tool cover -html=coverage.out 生成带颜色标注的 HTML 报告，这是目前最接近「看到哪行被执行」的方式。但它仍有局限：
立即学习“go语言免费学习笔记（深入）”；
- 绿色仅表示该语句所在的基本块被执行过，不等于该语句逻辑被充分验证（比如
if x > 0 { ... }里只测了x=1，x=-1分支仍是红色，但你可能误以为“只要绿了就安全”） - 无法区分「执行过」和「影响过结果」——比如某行日志打印语句被执行了，但它对业务逻辑无任何作用，覆盖它并不能提升质量
- 如果用了
go:generate或 embed.FS，生成的代码默认不参与覆盖率统计，得手动加//go:build ignore或调整构建 tag
CI 里自动检查「测试必须覆盖新增代码」靠谱吗？
不靠谱，至少不能只靠 -cover 原生能力。Go 没有增量覆盖率工具，go test 总是全量跑包，无法识别「这次 PR 新增了 a.go 的第 23–27 行，必须让测试覆盖它们」。
- 主流做法是结合 git diff +
go list -f '{{.GoFiles}}'找出变更文件，再用第三方工具（如gocov+gocov-html）做 diff 覆盖分析，但维护成本高、易误报 - 更务实的替代方案：在 PR 检查中强制要求新函数/方法必须有对应测试文件（命名匹配），并用
staticcheck检查未使用变量、无意义分支，这些比行覆盖更能暴露低质代码 - 真正的风险点往往不在“没覆盖的行”，而在“覆盖了但没断言”的地方——比如
err := doSomething(); if err != nil { log.Fatal(err) }，测试里只调用不校验 err，覆盖率 100%，但错误处理完全没验
行数只是表象，执行路径和断言质量才是关键。盯着数字容易忽略真正该 review 的东西：边界条件有没有测、错误分支有没有走、并发场景有没有压。
