Go项目调试应优先使用dlv而非go run，正确安装、启动（dlv debug）、设置断点（关注goroutine层级）、精准打印变量（p/args/locals），生产环境则用trace+log+pprof组合分析。
Go 项目跑不起来、变量值对不上、协程卡死——不是代码写得烂，是调试没用对工具和姿势。
dlv 调试器比 go run 更值得优先装
Go 自带的 go run 只负责执行，出错就抛堆栈，没法查中间状态。真正要定位逻辑问题，必须上 dlv（Delve）。它不是“可选插件”，而是 Go 生产级调试的事实标准。
- 安装只需一条命令：
go install github.com/go-delve/delve/cmd/dlv@latest
- 启动调试时别直接
dlv exec ./main，优先用dlv debug（自动编译 + 加载调试信息，避免因优化导致变量不可见） - Mac M 系列用户注意：如果
dlv启动报could not launch process: could not get pid，大概率是没关 SIP 或未授权开发者工具，xcode-select --install和重启终端常能解决 - VS Code 用户请确认已安装
Go扩展，并在.vscode/launch.json中使用"type": "dlv"，而非过时的"type": "go"
断点设在哪？看清楚 goroutine 和调用栈层级
Go 的并发模型让传统单线程调试思维失效。一个 fmt.Println 看似简单，但可能被 17 个 goroutine 同时触发——你停下的那个，未必是你想查的那个。
- 用
dlv命令行时，先执行goroutines查所有活跃 goroutine，再用goroutine <id> bt</id>看它的完整调用栈 - 断点别只设在函数入口，比如
http.HandleFunc("/api", handler)，真正逻辑可能在handler内部嵌套的闭包或defer里，得进到具体行号下断 -
break main.go:42是静态断点；break runtime.gopark这类运行时函数断点，适合排查 goroutine 卡死，但会频繁触发，慎用 - VS Code 中点击行号左侧加断点默认是“全 goroutine 生效”，如需只在特定 goroutine 停，得配合条件断点：
goroutine == 123 && user.ID > 0
print 不够用，要用 p / args / locals 精准捞值
新手习惯狂打 fmt.Printf，结果日志刷屏、并发输出错乱、还污染生产代码。dlv 内置的表达式求值才是干净解法。
立即学习“go语言免费学习笔记（深入）”；
-
p req.URL.Path直接打印请求路径，支持链式访问、类型断言（p req.Context().Value("user").(*User)） -
args显示当前函数入参，locals显示局部变量，比翻源码快得多；但注意：若变量被编译器优化掉（如未被后续使用），locals里不会出现 - 想看 map 或 struct 全貌？别用
p myMap（可能只显示地址），改用p *myMap或pp myMap（pretty print） - 调试 http.Server 时，
net.Listener类型变量默认只显示字段名，加config命令开启详细模式：config substitute-path /home/user/go /go可修复路径映射问题
线上环境不能 dlv？那就靠 trace + log + pprof 组合拳
生产环境禁用 dlv 是常态。这时候调试不是“暂停看变量”，而是“埋点抓证据”。Go 的内置工具链足够支撑闭环分析。
-
go tool trace是唯一能看清 goroutine 生命周期、阻塞事件、GC 毛刺的工具。生成 trace 文件后用go tool trace trace.out打开交互界面，重点看 “Goroutine analysis” 面板 - 日志别只写
log.Println("failed")，用log.WithFields（如zerolog）或至少带上reqID和时间戳，否则多请求混在一起等于没日志 -
runtime/pprof不只是看 CPU：用pprof.Lookup("goroutine").WriteTo(..., 1)抓当前所有 goroutine stack，比kill -SIGQUIT更可控；内存泄漏则用pprof.WriteHeapProfile配合go tool pprof分析 top allocs - 如果连日志都看不到，检查是否启用了
GODEBUG=gctrace=1或GORACE=1，它们会在 stderr 输出底层行为，有时比业务日志更早暴露问题
调试 Go 项目最常被忽略的，是 runtime 行为本身：GC 触发时机、调度器抢占、netpoll wait 状态。这些不会出现在你的代码里，但会决定你的断点停在哪、变量值为什么突然变、goroutine 为什么迟迟不调度——盯住 runtime 包里的关键符号，比多加十个 fmt 有用得多。
