在GoLand的「Debugger」面板「Goroutines」标签页中，可查看所有活跃goroutine调用栈；阻塞在channel上的goroutine通常停在runtime.gopark、runtime.chansend或runtime.chanrecv，展开栈追踪即可定位具体代码行。
GoLand里怎么看哪个goroutine卡在channel操作上
直接看「Debugger」面板的「Goroutines」标签页，里面会列出所有活跃 goroutine 的当前调用栈。阻塞在 channel 上的 goroutine 通常停在 runtime.gopark 或 runtime.chansend/runtime.chanrecv 这类函数里，展开它的 stack trace，就能看到具体哪一行代码（比如 ch 或 <code>）卡住了。
注意：如果 goroutine 状态显示为 waiting 或 chan send，基本可以断定是未匹配的发送/接收导致的阻塞；若显示 select 且没走任何 case，可能是所有 channel 都不可用 + 缺少 default 分支。
- 确保 GoLand 启用了「Show goroutines in debugger」（Settings → Go → Debugger）
- 调试前加个断点在疑似问题区域附近，否则可能错过瞬时状态
- 不要只盯着 main goroutine——阻塞往往藏在后台 worker 里
为什么断点没停住但程序卡死了
常见原因是 channel 操作发生在你没设断点的 goroutine 里，而主线程早已退出或空转。GoLand 默认只挂起当前 goroutine，其他 goroutine 继续跑，导致你“看不见”它们的阻塞点。
解决办法是：在 Debug 配置里勾选「Suspend all goroutines on breakpoint」（Run → Edit Configurations → Go Toolchain → Debugger），这样任意 goroutine 停下时，所有 goroutine 都暂停，方便你全局观察状态。
- 无缓冲 channel 的
ch 卡住，90% 是因为没启动接收方 goroutine，或接收方还没走到 <code> - 带缓冲 channel 卡住，先查
len(ch)和cap(ch)：若len(ch) == cap(ch)，说明缓冲已满，得看下游消费是否滞后 - 用
for range ch却没关 channel，循环会永远等待，goroutine 状态常显示为chan recv
如何快速验证是不是死锁而不是逻辑慢
Go 运行时一旦检测到所有 goroutine 都在等 channel，会直接 panic 并输出 fatal error: all goroutines are asleep - deadlock!。但这个错误只在「彻底无事可做」时触发；如果还有 goroutine 在跑 timer、network wait 或空循环，就不会报死锁，而是静默卡住。
所以不能只等 panic，要主动检查：
- 在 Debug 控制台执行
goroutines命令（GoLand 调试控制台支持），看是否有大量 goroutine 停在chansend/chanrecv - 对关键 channel 变量执行求值：
len(myCh)、cap(myCh)、myCh == nil——nil channel的收发永远阻塞，且不会 panic，极难发现 - 检查是否重复 close：
close(myCh)被调了两次会 panic，但第一次 close 后再 send 也会阻塞（且不 panic）
调试时改 channel 缓冲大小能绕过阻塞吗
能临时绕过，但只是掩盖问题。比如把 make(chan int) 改成 make(chan int, 1)，原本卡住的 ch 就能立刻返回——但这不代表逻辑正确，只是把阻塞从「立刻发生」推迟到「缓冲填满后」。
真正该做的是：确认数据流节奏。如果上游每秒发 100 条，下游每秒只能处理 10 条，缓冲再大也撑不过几秒，最终还是满+阻塞+OOM。
- 开发期优先用无缓冲 channel：
make(chan int)，让阻塞立刻暴露，倒逼你补全 goroutine 配对 - 上线前才根据压测结果设缓冲，例如日志通道设
make(chan string, 1024)，但必须配套背压策略（如select+default丢弃） - 永远别用
make(chan T, 10000)当“保险丝”——它只会让内存爆得更安静
最易被忽略的一点：channel 关闭时机。多个生产者时，谁关、何时关、关几次，没有统一机制，靠人工协调极易出错。宁可用 sync.WaitGroup 等所有 sender 结束再关，也不要靠计时器或猜测。
