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% 就很稳”，但以下三类问题几乎从不进覆盖率统计，却高频导致线上事故：
立即学习“go语言免费学习笔记（深入）”；
- goroutine 生命周期管理：启动了没
defer wg.Done()，或select漏写了default导致永久阻塞 - context 取消传播：父 context cancel 后，子 goroutine 仍试图往已关闭 channel 写数据
- time.Now() 的硬依赖：测试里 mock 了时间，但调试时忘了关 mock，结果
dlv里看到的时间戳永远不对
dlv attach 到正在跑的进程里看 goroutine stack；测试写得再密，也只是你认为的路径——而程序实际走的，永远是它自己选的那条。 
