goland调试时默认不显示goroutine列表，需手动点击debug窗口右上角“show goroutines”按钮（或快捷键ctrl+shift+g/cmd+shift+g）启用；开启后frames面板顶部才出现goroutines标签页，可查看所有活跃协程及其栈帧。
GoLand调试时看不到goroutine列表？
默认不显示，不是Delve没采集到，是UI被折叠了。必须手动开启：点击Debug窗口右上角“Show Goroutines”按钮（图标是两个交错的圆圈），或按快捷键Ctrl+Shift+G（Windows/Linux）/Cmd+Shift+G（Mac）。开启后，左侧Frames面板顶部才会出现Goroutines标签页。
常见错误现象：断点停在select或ch 上，却只看到一个协程——其他并发上下文完全不可见。
若仍为空，检查两点：
- GoLand版本是否低于2023.3？旧版本需确保Delve启动参数含
--api-version=2 - 是否用了
go run -gcflags="-N -l"编译？缺少调试符号会导致Delve无法解析goroutine元数据
如何区分main goroutine和worker goroutine？
协程没有名字，但调用栈有规律可循。关键看Frames面板里每个goroutine的第一行函数名：
-
main goroutine一定以runtime.main开头 -
worker goroutine栈顶通常是runtime.goexit，第二层才是你的函数，比如worker或func·001
鼠标悬停在某个goroutine上，会显示其启动位置（如main.go:42），这是最直接的区分依据。如果多个goroutine都来自同一个for循环里的go f(i)，就得靠局部变量值（如i、id）人工识别——注意闭包捕获的变量可能被所有goroutine共享，导致值相同。
channel阻塞时为什么总卡在runtime.chanrecv？
这是正常底层行为，runtime.chanrecv和runtime.chansend只是阻塞点，不代表代码写错了。真正的问题往往出在channel生命周期或收发逻辑错配。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
不要只盯着栈帧，重点看三件事：
-
Variables面板里channel的状态：len、cap、closed字段是否为true - 谁在发、谁在收？有没有goroutine已退出却没关闭channel？
- 用
Evaluate Expression（Alt+F8）输入ch查看实际结构，确认closed字段
协程泄漏时怎么快速定位阻塞点？
线上runtime.NumGoroutine()持续上涨、堆栈大量出现chan receive或select状态，基本可判定泄漏。此时别看heap profile，直接抓goroutine堆栈。
推荐两种方式：
- 终端执行：
wget http://localhost:6060/debug/pprof/goroutine?debug=2 -O goroutine-blocked.gor（需提前导入_ "net/http/pprof"） - GoLand Profiler界面：菜单
Run → Start Profiling → Goroutines，采集后双击任意条目跳转源码
【关键操作】在火焰图中右键节点 → Filter by Stack Trace → 输入chan receive或time.Sleep，立即聚焦泄漏高发区。典型泄漏链包括：向已关闭channel发送、context未监听Done、timer未Stop——这些在堆栈里都有固定模式。
协程调试最易被忽略的点：你看到的goroutine列表，依赖于当前断点是否触发了完整的goroutine快照。如果程序正在高速创建/退出协程，而你没在合适时机暂停，就可能错过关键状态。建议配合runtime.NumGoroutine()日志 + 定期pprof抓取，而不是只依赖单次调试会话。
