17370845950

go test 不能替代调试，二者目标、手段、阶段均不同：测试是“找错”，调试是“定位并修错”；单元测试覆盖有限，难发现竞态、泄漏、第三方失败等问题，而调试可深入运行时状态精准修复。

go test 不能替代调试，二者目标不同、手段不同、作用阶段也不同。测试是“找错”，调试是“定位并修错”——就像体检报告和手术刀的关系：前者告诉你哪里可能有问题，后者才能切开看清楚、动手修复。

为什么 go test 发现不了所有问题？

单元测试只覆盖你显式编写的用例路径，对未声明的边界、并发竞态、资源泄漏、第三方交互失败等几乎无感。

• t.Errorf 只在断言失败时触发，而程序“没崩溃但逻辑歪了”（比如返回了错误的缓存值）常被忽略
• 基准测试 BenchmarkXxx 关注耗时，但不校验中间状态；go test -bench=. 跑出 0.34 ns/op 很漂亮，可如果函数悄悄改了全局变量，它完全不报警
• 表驱动测试再全，也难穷举真实环境中的输入组合（如含 Unicode 边界、超长 header、时区切换瞬间）

什么时候必须切到调试？

当你看到测试通过但程序在线上卡死、goroutine 泄漏、HTTP 返回 500 却没 panic、或 go test -race

报告 data race 但不知道哪两行在争——这时就得用调试手段。

• 用 dlv debug 启动，设断点在疑似位置：dlv debug --headless --listen=:2345 --api-version=2
• 在 IDE（如 VS Code）里连上 dlv，单步进 http.HandlerFunc，观察 req.Context().Value() 是否被意外覆盖
• 用 runtime.Stack() 或 debug.ReadGCStats() 在关键节点打日志，比 fmt.Println 更轻量、更可控

testing.T 和 dlv 怎么配合才不重复劳动？

测试不是调试的替代品，而是调试的“路标”。写测试时就该埋好调试线索。

• 在 TestXxx 里加 t.Log("state:", obj.Status, "cache hit:", hit)，运行时用 go test -v 看上下文，比盲猜快得多
• 对易出错路径（如重试逻辑、超时分支）单独写 TestXxxWithTimeout，并在函数内用 if testing.Verbose() { log.Printf(...) 控制日志粒度
• 避免在测试中直接调 os.Exit(1) 或 panic——这会让 dlv 失去控制权；改用 t.Fatal，它能被测试框架捕获并继续执行后续清理

容易被忽略的调试盲区

很多人以为 “go test 覆盖率 95% 就很稳”，但以下三类问题几乎从不进覆盖率统计，却高频导致线上事故：

• goroutine 生命周期管理：启动了没 defer wg.Done()，或 select 漏写了 default 导致永久阻塞
• context 取消传播：父 context cancel 后，子 goroutine 仍试图往已关闭 channel 写数据
• time.Now() 的硬依赖：测试里 mock 了时间，但调试时忘了关 mock，结果 dlv 里看到的时间戳永远不对

真正卡住的时候，别反复改测试用例，先 dlv attach 到正在跑的进程里看 goroutine stack；测试写得再密，也只是你认为的路径——而程序实际走的，永远是它自己选的那条。