必须用dlv debug启动才能稳定调试goroutine，它自动编译、注入调试符号，使所有goroutine可枚举和暂停；dlv exec需配合-go build -gcflags="all=-N -l"，否则goroutine列表为空或堆栈不全。
dlv debug 是唯一能稳定调试 goroutine 的入口
直接 go run 启动的程序无法看到 goroutine 状态，变量也常显示为 <optimized out>。必须用 dlv debug 启动——它会自动编译、注入调试符号，并让所有 goroutine 可被枚举和暂停。
-
dlv debug --headless --listen=:2345 --api-version=2 --accept-multiclient是最稳妥的本地调试命令 - 若想在断点处看到每个 goroutine 的完整调用栈，启动时加
--only-same-user=false（Linux/macOS 下避免权限拦截） - 别用
dlv exec调试未带调试信息的二进制：除非你明确用go build -gcflags="all=-N -l"编译过，否则 goroutine 列表为空或堆栈不全
VS Code 中必须显式配置 dlvLoadConfig 才能展开 goroutine 变量
默认配置下，结构体字段被截断、map/slice 只显示长度、goroutine 局部变量不可见——这不是 bug，是 dlvLoadConfig 的保守策略。
- 在
launch.json的dlvLoadConfig里设"maxStructFields": -1，否则嵌套结构体字段全丢 -
"followPointers": true必须开启，否则指针字段显示为地址而非内容 -
"maxArrayValues": 128比默认 64 更实用，尤其查 channel 缓冲区或任务队列时
远程调试时 goroutine ID 和 trace ID 必须对齐日志
仅靠 IDE 查看 goroutine 列表不够——你得知道哪个 goroutine 触发了某条日志。这需要运行时注入上下文，而不是靠事后猜。
- 用
runtime.GoroutineID()（需第三方包如github.com/felixge/fgprof或自行封装）在关键入口打日志，格式如[goro=12345] received request - 配合
context.WithValue注入 trace ID，并在日志中统一输出，例如log.Printf("[trace=%s, goro=%d] processing", traceID, runtime.GoroutineID()) - VS Code 断点触发时，右下角状态栏会显示当前 goroutine ID；和日志里的 ID 对上，就能锁定具体协程路径
pprof + dlv 联合定位 goroutine 泄漏比单用更准
单纯看 dlv 的 goroutine 列表只能看到“活着”，但看不出为什么活这么久；pprof 能暴露阻塞点，两者交叉验证才可靠。
立即学习“go语言免费学习笔记（深入）”；
- 先用
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2抓 goroutine 堆栈快照，找大量select或chan receive的 goroutine - 再在 VS Code 里用
dlv连接同一进程，在疑似阻塞函数（如ch <- val）设断点，观察 channel 是否已满、接收方是否卡住 - 注意：
pprof的blockprofile 需开启runtime.SetBlockProfileRate(1)，否则默认不采样
实际调试中最容易忽略的是：goroutine 的生命周期与调试器视角不同步。比如一个 goroutine 在断点前已退出，dlv 就不会列出它——这时得靠日志 timestamp + goroutine ID 回溯，而不是只盯着调试器界面。
