断点命中后看不到其他 goroutine 是 delve 默认行为：仅加载当前活跃 goroutine 调用栈，需在 debug console 输入 goroutines 查看全部，再用 goroutine id bt 查指定栈。
断点命中后看不到其他 goroutine？这是 Delve 的默认行为
VSCode 本身不主动列出所有 goroutine，它只在暂停时把当前正在执行的 goroutine（通常是 main）展示在 CALL STACK 面板里。其他 goroutine 如果处于 waiting、chan send、semacquire 或已退出，根本不会自动出现——这不是 UI 缺失，而是 Delve 的快照机制决定的。
- Delve 默认只加载「当前活跃」goroutine 的调用栈，节省开销
- goroutine 是瞬时资源，退出后无法回溯；没停住的 goroutine 不会出现在快照中
- 必须手动触发，且仅限调试暂停状态（比如断点命中、手动 Pause）
- 依赖 Delve 版本 ≥ 1.21，并启用
dlv dap模式（VS Code Go 扩展 v0.38+ 默认启用）
在 DEBUG CONSOLE 中查全部 goroutine 的正确姿势
别在代码里写 goroutines，它不是 Go 函数，是 Delve 调试器命令，只能在 VSCode 底部的 DEBUG CONSOLE 里输入。
- 确保程序已暂停（F5 启动后断点命中 / 点击暂停按钮）
- 打开 DEBUG CONSOLE（Ctrl+Shift+Y 或 View → Debug Console）
- 输入：
goroutines，回车 - 输出示例：
ID State Location 1 running runtime/proc.go:250 17 waiting myapp/main.go:42 18 chan send myapp/handler.go:66
-
State字段最关键：waiting多半卡 channel 或锁；chan send表示正阻塞在发送端；semacquire基本是sync.Mutex或sync.WaitGroup竞争
想看某个 goroutine 的完整调用栈？用 bt + ID
光有 ID 和 State 不够，得定位到具体哪行代码卡住。这时候要用 Delve 的 bt（backtrace）命令配合 goroutine ID。
- 比如上例中 ID 为
17的 goroutine 卡在myapp/main.go:42，但你想确认它怎么走到这的 - 在 DEBUG CONSOLE 输入：
goroutine 17 bt - 输出会显示从入口函数到阻塞点的完整调用链，包括匿名函数名（如
func·001）和内联信息 - 注意：如果该 goroutine 已退出，
goroutine 17 bt会报错invalid goroutine—— 这说明它已经结束了，快照里留不下痕迹
为什么改了代码、加了 log，还是抓不到 goroutine 卡点？
常见误区是以为“加日志就能看到 goroutine 执行流”，但日志输出本身不改变调度时机，更不保证 goroutine 在你期望的位置暂停。
- goroutine 可能太快执行完，log 还没刷出就退出了；用
time.Sleep强制延缓反而可能掩盖真实竞争条件 - channel 操作无缓冲时，
ch 会直接阻塞直到有接收方，但如果你没在接收端设断点，就看不到谁在等它 - 多个 goroutine 同时操作一个
sync.Mutex，只在加锁前设断点没用；得在mu.Lock()调用内部或semacquire状态里查 ID 对应的 bt - 真正难排查的是「goroutine 泄漏」：启动了却没退出，也不报错。这种必须靠
goroutines命令反复比对 ID 数量变化，或结合pprof/goroutine抓堆栈快照
复杂点在于：goroutine 状态不是实时刷新的，每次 goroutines 都是一次性快照；而你真正想盯的，往往是那个刚阻塞、还没来得及被你切过去看的 goroutine。
