goland profiler 对死锁完全无效，因死锁触发 runtime panic 后进程毫秒级退出，profiler 来不及采样；唯一可靠线索是 panic 输出的“fatal error: all goroutines are asleep - deadlock!”及附带的 goroutine 堆栈。
GoLand 的性能剖析工具（Profiler）对死锁完全无效——死锁发生时程序已 panic 退出，Profiler 来不及采集任何数据；真正能定位死锁的，只有运行时输出的 fatal error: all goroutines are asleep - deadlock! 和附带的 goroutine 堆栈。
为什么 GoLand Profiler 在死锁场景下无用
Profiler 依赖持续运行的程序来采样 CPU、内存、goroutine 状态等指标。而死锁触发的是 Go 运行时强制终止：所有 goroutine 阻塞 → runtime 检测到无活跃协程 → 立即 panic 并打印堆栈 → 进程退出。整个过程毫秒级完成，Profiler 根本没有启动或上报的机会。
你在 GoLand 里点「Profile」再运行，看到的只会是“进程已退出”或空白图表。别浪费时间配 pprof 采样参数或等火焰图生成——它不适用于死锁诊断。
- Profiler 只适用于“程序还在跑但变慢/卡顿/吃内存”的场景
- 死锁不是性能问题，是逻辑错误导致的程序终局状态
- GoLand 的 CPU/Memory Profiler 启动后会注入运行时 hook，但死锁发生得太快，hook 来不及注册
死锁唯一可靠的线索：panic 日志里的 goroutine dump
看到 fatal error: all goroutines are asleep - deadlock! 就该立刻停手，翻日志末尾那段以 goroutine N [state] 开头的列表——这才是你唯一的证据链。
重点关注三类信息：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
maingoroutine 卡在哪？比如ch 、<code>、<code>wg.Wait()、mu.Lock() - 其他 goroutine 是否全停在同一个阻塞点？例如全部卡在
runtime.chansend或sync.runtime_SemacquireMutex - 有没有 goroutine 卡在
init函数里？说明包初始化阶段就循环依赖，不会显示 channel 相关关键词
示例中若看到：
goroutine 1 [chan send]:
main.main()
/tmp/main.go:5 +0x32
goroutine 2 [chan receive]:
main.worker()
/tmp/main.go:9 +0x4a
说明 main 发送、worker 接收，但 worker 没执行完就退出了，或者 channel 未关闭导致 for range ch 永不结束。
GoLand 能帮上忙的实操动作（仅限辅助）
GoLand 不分析死锁，但它能帮你更快看清 panic 日志、跳转代码、折叠干扰信息：
- 在 Run 窗口右键 → “Fold Lines That Contain” → 输入
SCHED，过滤掉GODEBUG=schedtrace=1000的调度日志（避免刷屏） - 日志里点击
main.go:5这类路径，直接跳转到卡点行——但别指望它高亮“问题”，它只做文本跳转 - 把
defer mu.Unlock()手动写在每个return前，而不是只放在函数末尾；GoLand 的代码检查不会报这个错 - 在 GoLand 的 Run Configuration → Environment variables 里加
GODEBUG=schedtrace=1000，观察是否长期出现goroutines: 1—— 这比等 panic 更早暴露全员阻塞
真正该用的工具链（绕过 GoLand）
死锁定位必须脱离 IDE 依赖，靠命令行工具直连运行时信号：
- 用
go tool trace：提前起http.ListenAndServe("localhost:6060", nil)，运行后执行go tool trace http://localhost:6060/debug/trace?seconds=5，打开 Web UI → “Goroutine” 标签页 → 筛选chan send状态，看谁在等谁 - 用
curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'：前提是程序没 panic，还在“假死”状态；重点搜sync.(*Mutex).Lock或runtime.chansend - 用
dlv debug：虽然死锁时无法 step，但可运行到临界点前，用goroutines和goroutine N bt查看各协程实时栈
最常被忽略的一点：死锁 panic 后日志不可逆，清空终端 = 彻底丢失线索。看到那句 fatal error，第一反应不是改代码，是复制整段日志——包括 goroutine dump 的每一行。
