<p>死锁发生时程序立即panic终止，不触发defer、无堆栈回溯，唯一线索是panic日志末尾的goroutine调用栈；看到“fatal error: all goroutines are asleep - deadlock!”需立即分析main goroutine卡点，如卡在ch、<-ch、wg.Wait()或mu.Lock()。</p>
GoLand 里看不到死锁 panic 日志？先确认是不是真死锁
Go 运行时检测到 all goroutines are asleep - deadlock! 会立刻终止进程，不触发 defer、不写日志、不响应 HTTP 请求——GoLand 的 Run 窗口如果只显示空白或突然退出，大概率就是它。别急着点「Debug」，先看控制台最后一段输出：有没有那句 fatal error？没有，就不是死锁，可能是卡在 syscall（比如文件读、网络超时）或活锁。
常见误判场景：
- Run 窗口卡住几秒后才退出 → 很可能已 panic，但 GoLand 默认折叠了 panic 堆栈，手动拖动滚动条到底部找
fatal error: all goroutines are asleep - deadlock! - 程序没退出，但 UI 停止响应 → 不是死锁，是主 goroutine 卡在阻塞操作（如未设 timeout 的
http.Get），该用 pprof 或 trace 查，不是死锁排查路径 - GoLand 的「Attach to Process」连上后看到大量 goroutine 处于
runtime.gopark→ 若全是chan send或sync.(*Mutex).Lock，且数量稳定不变，才是死锁信号
GoLand 调试器对死锁基本无效，别浪费时间单步
死锁发生时，所有 goroutine 已进入不可唤醒等待态（ch <- v、<-ch、wg.Wait()、mu.Lock()），GoLand 的断点和 Step Into 完全无法触发——因为没代码在执行，调度器已放弃调度它们。你设的断点永远不会命中。
真正该做的三件事：
- 启动前加环境变量：
GODEBUG=schedtrace=1000，在 GoLand 的「Run Configurations → Environment Variables」里填入，运行后看 Console 每秒输出的SCHED行：若goroutines: 1持续 3 秒以上，且你代码本该起多个 goroutine，说明其余已卡死 - 确保代码开头有
import _ "net/http/pprof"和go http.ListenAndServe("localhost:6060", nil)，这样即使没 panic，也能在卡住时用浏览器访问http://localhost:6060/debug/pprof/goroutine?debug=2抓快照 - 别依赖 GoLand 自带的「Goroutines」视图（View → Tool Windows → Goroutines），它只显示当前 runnable 的 goroutine；死锁时这个面板往往是空的或只剩 main，没参考价值
用 GoLand 配合 go tool trace 定位 channel 阻塞源头
GoLand 本身不提供 trace 分析能力，但可以无缝配合 go tool trace：关键在于让 trace 数据能被 GoLand 启动的进程生成。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
操作步骤：
- 在 GoLand 的「Run Configurations」里，Program arguments 填
-gcflags="-l" -ldflags="-s -w"（可选，减小二进制体积便于 trace） - 代码里确保已导入
import _ "net/http/pprof"，并在main()开头加go http.ListenAndServe("localhost:6060", nil) - 运行程序后，立刻在终端执行：
go tool trace http://localhost:6060/debug/trace?seconds=5，下载trace.out - 双击
trace.out文件（GoLand 默认关联），或手动执行go tool trace trace.out打开 Web UI → 切到「Goroutine」页 → 在搜索框输入chan recv或chan send
典型线索：
- 某个 goroutine 状态长期为
chan recv，且对应 sender goroutine 根本没出现 → 说明接收方没启动，或启动后已 panic 退出 - 多个 goroutine 全卡在
chan send，而唯一接收 goroutine 卡在mu.Lock()→ 锁阻塞导致 channel 无法消费，根源在 mutex，不是 channel 本身 - trace 里看到
select {}状态持续 >1s → 99% 是忘了关 channel 或没监听ctx.Done()，直接定位到那个 goroutine 的启动位置
最容易被 GoLand「高亮」误导的三个地方
GoLand 的静态分析（比如灰色变量、波浪线警告）对死锁几乎无用，反而容易引错方向：
-
for v := range ch被标黄说「ch may be nil」→ 实际问题可能是没人 close(ch)，但 GoLand 不检查关闭责任归属 -
wg.Add(1)和wg.Done()都存在，GoLand 认为「没问题」→ 但若wg.Add(1)在 goroutine 内部调用（而非启动前），就会漏计数，死锁发生在wg.Wait() -
mu.Lock()被自动补全成defer mu.Unlock()→ 看似安全，但如果 defer 在错误作用域（比如在 if 分支里），或者 goroutine panic 后 Unlock 没执行，锁就永远卡住
真正要盯的，永远是 panic 日志里那一堆 goroutine 堆栈——GoLand 只负责把它们完整显示出来，剩下的，得你自己扫 ch <-、<-ch、wg.Wait()、mu.Lock() 这几处，看谁等谁、谁没动。
