GoLand调试时默认不显示goroutine列表，需手动点击Debug窗口右上角“Show Goroutines”按钮（或快捷键Ctrl+Shift+G/Cmd+Shift+G）启用；开启后Frames面板顶部出现Goroutines标签页，可查看所有活跃协程及其栈帧。
GoLand 调试时看不到 goroutine 列表？
默认情况下，GoLand 的 Debug 视图不会自动展开 goroutine 信息，导致你无法直观看到当前运行的协程状态。这不是 Delve 没采集到，而是 UI 层级被折叠了。
必须手动打开：Debug 窗口右上角的 “Show Goroutines” 按钮（图标为两个交错的圆圈），或按快捷键 Ctrl+Shift+G（Windows/Linux）/Cmd+Shift+G（Mac）。开启后，左侧 Frames 面板顶部会出现 Goroutines 标签页，点击即可查看所有活跃 goroutine 及其栈帧。
- 未启用该开关时，即使断点停在
select或channel操作上，你也只能看到当前 goroutine，其他并发上下文完全不可见 - 某些低版本 GoLand（如低于 2023.3）可能需先确保 Delve 启动参数含
--api-version=2，否则 goroutine 列表为空 - 若仍为空，检查是否用了
go run -gcflags="-N -l"编译——缺少调试符号会导致 Delve 无法解析 goroutine 元数据
如何在调试中区分 main goroutine 和 worker goroutine？
协程没有名字，但 GoLand 会根据启动方式标注常见模式。关键不是靠标签，而是结合 Frames 中的调用栈和变量作用域来判断。
main goroutine 一定以 runtime.main 开头；worker goroutine 多数来自 go func() { ... }() 或 go someFunc(...)，其栈顶通常是 runtime.goexit，第二层才是你的函数名。注意看 Frames 面板里每个 goroutine 的第一行函数名。
立即学习“go语言免费学习笔记（深入）”；
- 鼠标悬停在某个 goroutine 上，会显示其启动位置（如
main.go:42），这是最直接的区分依据 - 如果多个 goroutine 启动位置相同（比如都来自同一个
for循环中的go语句），就需依赖局部变量值（如循环变量i、传入的id）来人工识别 - 避免在 goroutine 内部用匿名函数捕获外部变量，否则调试时所有 goroutine 显示的变量值可能相同（闭包共享）
调试 channel 阻塞时为什么 goroutine 总是卡在 runtime.chanrecv？
这是正常现象，runtime.chanrecv 和 runtime.chansend 是底层阻塞点，不代表代码写错了。真正的问题往往出在 channel 的生命周期或发送/接收逻辑不匹配。
不要只盯着栈帧，重点看三件事：Variables 面板里的 channel 状态（len、cap、closed）、谁在发、谁在收、有没有 goroutine 已退出却没关闭 channel。
- 用
Evaluate Expression（Alt+F8）输入ch查看 channel 实际结构，确认closed字段是否为true - 检查是否有 goroutine 在
select中监听了该 channel，但未提供default分支，导致永久等待 - 若使用带缓冲 channel，
len(ch) == cap(ch)且无人接收，后续发送就会卡死——此时 goroutine 停在runtime.chansend，而非 recv
学习阶段用 GoLand 调试，哪些操作最容易误判问题？
初学者常把调试器行为当成程序 bug：比如单步进入标准库函数、看到未初始化变量显示零值、或因 goroutine 调度顺序不同而怀疑逻辑错误。
Delve 默认会跳过标准库（runtime、sync 等），但如果你点了 Step Into（F7）又没禁用“Step into library code”，就会掉进汇编或内部实现里，浪费时间且无意义。
- 务必在
Settings > Build, Execution, Deployment > Debugger > Stepping中勾选Do not step into the libraries - 变量显示
<not accessible>或空值，不一定是 nil——可能是变量尚未分配，或作用域已退出，别急着改逻辑 - goroutine 执行顺序非确定性是 Go 的特性，不是调试器 bug。用
time.Sleep强制顺序只是临时验证手段，不能用于生产 - 调试时加的
fmt.Println可能改变 goroutine 调度节奏（IO 操作引入调度点），导致问题“消失”，这叫 Heisenbug，得靠断点和变量监视来定位
runtime.gopark 不代表卡死，看到 len(ch) == 0 也不代表没人发，得结合上下文读代码，而不是读栈帧。 
