Go代码覆盖率需用go test -coverprofile生成coverage.out再通过go tool cover -html生成HTML报告查看具体覆盖情况，绿色为覆盖、红色为未覆盖、灰色为不可覆盖代码。
怎么看 Go 代码覆盖率？
Go 原生支持覆盖率统计，不需要额外工具。最直接的方式是用 go test -cover 查看整体覆盖率百分比，但这个数字太笼统，实际开发中更常用的是生成 HTML 报告来定位具体哪行没覆盖到。
执行以下命令生成可交互的覆盖率报告：
go test -coverprofile=coverage.out -covermode=count ./... go tool cover -html=coverage.out -o coverage.html
打开 coverage.html 就能看到每行代码的执行次数（covermode=count 模式），绿色表示覆盖，红色表示未覆盖，灰色是不可覆盖的代码（比如 default 分支、空行、函数签名等）。
注意：go test -cover 默认只跑当前包，如果想包含子包，得加 ./...；漏掉这点会导致覆盖率虚高。
为什么覆盖率卡在 80% 左右上不去？
常见瓶颈不是逻辑复杂，而是几类“看似 trivial 实则难测”的代码：
- 错误路径（
err != nil 分支）：比如文件打开失败、网络超时、JSON 解析出错——这些需要 mock 或构造异常输入，很多人直接跳过
- 边界条件：空切片、nil 接口、负数 ID、超长字符串——测试用例没写全，
if len(s) == 0 这种分支就悬在那里
- 日志和监控打点：比如
log.Printf、prometheus.Inc() 这类副作用调用，不 mock 就无法触发，但 mock 又容易让测试变重
- panic 路径：比如
assert 类函数或显式 panic("should not happen")，需用 defer recover() 捕获，否则测试直接退出
怎么把覆盖率推到 90%+？
关键不是堆用例，而是聚焦“可测性”和“最小必要覆盖”：
err != nil 分支）：比如文件打开失败、网络超时、JSON 解析出错——这些需要 mock 或构造异常输入，很多人直接跳过if len(s) == 0 这种分支就悬在那里log.Printf、prometheus.Inc() 这类副作用调用，不 mock 就无法触发，但 mock 又容易让测试变重assert 类函数或显式 panic("should not happen")，需用 defer recover() 捕获，否则测试直接退出优先确保以下三类代码有对应测试：
- 所有公开导出的函数（
func DoX(...)），哪怕只是简单封装，也要验证输入输出和 error 返回 - 每个
switch的非default分支，以及default本身（哪怕它只打日志） - 任何带
if err != nil的地方，必须有至少一个测试让err非 nil —— 用testify/mock、io.ErrUnexpectedEOF或自定义 error 实现
避免陷阱：covermode=count 比 atomic 更准，适合增量推进；别依赖 -coverpkg 强行拉高数字，那只是把依赖包的覆盖率算进来，对本包质量无意义。
哪些代码可以合理忽略？ Go 官方不鼓励 100% 覆盖，有些代码确实不值得测：
真正难的是判断“哪里该停”。90% 是个实用分水岭：再往上投入产出比断崖下跌，而低于 85% 往往意味着核心错误流或边界没兜住。
