vscode断点后call stack只显示main是因为delve默认仅展示活跃goroutine；需暂停程序、delve≥1.21且启用dlv-dap模式，才能在debug console用goroutines命令查看全部goroutine状态并定位阻塞点。
断点停住后 CALL STACK 里只看到 main，其他 goroutine 哪儿去了
VSCode 默认不展示非活跃 goroutine，这不是 UI 缺失，而是 Delve 的快照机制决定的。只有当前正在执行（running）或刚被调度暂停的 goroutine 才会自动出现在 CALL STACK 面板；waiting、chan send、semacquire 状态的 goroutine 全部被隐藏，直到你手动触发。
必须满足三个前提才能查到它们：
- 程序已暂停（断点命中 / 点击 Pause 按钮）
- Delve 版本 ≥ 1.21（
dlv version可验证） - VS Code Go 扩展启用了 dlv dap 模式（v0.38+ 默认启用）
不满足任一条件，goroutines 命令在 DEBUG CONSOLE 中会返回空或报错。
在 DEBUG CONSOLE 中列出全部 goroutine 并定位阻塞点
goroutines 是 Delve 命令，不是 Go 函数，不能写在代码里。它只在调试暂停状态下生效，输出类似：
ID State Location 1 running runtime/proc.go:250 17 waiting myapp/main.go:42 18 chan send myapp/handler.go:66
State 字段最关键：
-
waiting：大概率卡在select或未关闭的 channel 接收端 -
chan send：发送方正阻塞，说明接收方缺失或 channel 已满且无消费逻辑 -
semacquire：常见于sync.Mutex.Lock()或sync.WaitGroup.Wait()未释放
拿到 ID 后，用 goroutine 17 bt 查完整调用栈——注意：如果该 goroutine 已退出，命令会报 invalid goroutine，说明它早结束了，快照里留不下痕迹。
pprof + goroutine dump 是泄漏确认的唯一可靠手段
VSCode 调试只能抓“瞬间快照”，而协程泄漏是随时间累积的现象。真正确认泄漏，必须靠运行时导出 goroutine 列表：
- 启动服务时加
-http=:6060参数（或用net/http/pprof注册） - 请求
http://localhost:6060/debug/pprof/goroutine?debug=2获取全量堆栈 - 对比两次 dump（间隔 30s+），看数量是否持续增长、是否有重复 pattern（如固定行号卡在
ch ）
常见泄漏模式直接对应 dump 内容：
- 大量
runtime.gopark+myapp/xxx.go:xx→ 通道未关闭或 context 缺失 - 全是
net/http.(*persistConn).readLoop→ HTTP 客户端未设超时或连接复用失控 - 第三方库名反复出现（如
pgx.(*Conn).listenLoop）→ 忘记调用Close()
为什么加 log 还是抓不到泄漏点
日志本身不改变 goroutine 调度时机，更不会让它“停下来等你看见”。典型失效场景：
- 协程执行太快，
log.Printf还没刷到 stdout 就已退出（缓冲未刷新） - 用
time.Sleep强制延缓，反而掩盖真实竞争条件（比如掩盖了本该发生的 panic 或 channel 关闭时机） - 日志输出到
stdout，但 VSCode 调试配置为"console": "internalConsole"，导致日志被 DAP 截断
真要打日志辅助排查，优先写到 stderr（DAP 默认透传），并确保末尾换行或显式调用 os.Stdout.Sync()。
协程泄漏的本质是资源生命周期脱离控制，调试器能帮你看清“此刻谁卡在哪”，但无法替代对 context 传递、channel 关闭责任、第三方库清理义务的代码级审查。
