goland无法主动检测死锁，真正暴露死锁的是go运行时panic的“fatal error: all goroutines are asleep - deadlock!”及其附带的goroutine堆栈；调试器因无指令流可接管而失效，关键在于主动复现、读懂堆栈、严防unlock遗漏。
GoLand 本身不提供运行时死锁检测能力，它只能辅助你定位潜在死锁点——真正暴露死锁的，是 Go 运行时在程序卡住时自动打印的 fatal error: all goroutines are asleep - deadlock! 错误。所以分析死锁，关键不是“在 GoLand 里点哪”，而是「怎么让死锁更快暴露 + 怎么看懂堆栈 + 怎么避免漏掉 Unlock」。
为什么 GoLand 的 debugger 对死锁无能为力
GoLand 调试器基于 delve，而 delve 在遇到死锁时无法主动中断或回溯——因为此时所有 goroutine 都已阻塞，没有可执行指令流供调试器接管。你看到的只是程序静止、CPU 归零、控制台无输出。这时候再点「Step Into」或「Evaluate Expression」都无效。
真正有用的信号只有两个：
- 终端里突然冒出的
fatal error: all goroutines are asleep - deadlock! - 运行时打印出的完整 goroutine dump（含每个 goroutine 的当前调用栈）
这个 dump 不是 GoLand 自动生成的，必须靠你手动触发或靠程序自己 panic 后输出。所以别指望调试器“帮你发现死锁”，它只负责展示你 already have 的线索。
如何让死锁快速复现并拿到有效堆栈
死锁常发生在开发环境难以复现（比如只在高并发压测时出现），这时要主动制造条件：
- 把
sync.Mutex或sync.RWMutex的Lock()/RLock()调用前加日志，例如：log.Printf("locking shard %d", index) - 在
defer mutex.Unlock()前也加日志，确认是否真被执行 - 用
runtime.NumGoroutine()定期打点，观察 goroutine 数是否持续增长（可能是锁没释放导致新 goroutine 卡住排队） - 启动时加
GODEBUG=mutexprofile=1环境变量，运行一段时间后访问http://localhost:6060/debug/pprof/mutex查看锁竞争热点（需启用net/http/pprof）
一旦复现死锁，终端输出的 goroutine dump 会列出每个 goroutine 的状态，重点关注标着 semacquire 或 runtime.gopark 的那一行——它后面跟着的函数调用链，就是卡在哪个 Lock() 或 chan receive 上。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
最容易被忽略的 Unlock 漏写场景
不是所有 Unlock() 都会漏，但以下几种情况高频踩坑：
- 函数中间有多个
return，只在末尾写了defer mutex.Unlock()—— 这个defer只对当前函数生效，不会覆盖所有出口 - 用了
if err != nil { return }之后才加defer mutex.Lock()，结果锁根本没拿到就退出了，后续还试图Unlock() - 在
select里对 channel 操作时，某个分支里忘了mutex.Unlock()，而其他分支又依赖该锁继续执行 - 用
sync.Pool复用带锁结构体，但没重置内部 mutex 状态，导致下次取出时 mutex 已处于 locked 状态
正确做法永远是：锁的 Lock() 和对应 Unlock() 必须在同一个作用域内配对，且 defer 必须紧跟在 Lock() 后面，不能隔行、不能被条件包裹。
分段锁（shard）下死锁的特殊表现
像 ConcurrentDict 这类分片结构，死锁往往不是单个锁的问题，而是多个 shard 锁之间的循环等待。例如：
- goroutine A 拿了 shard[0].mutex，想拿 shard[1].mutex
- goroutine B 拿了 shard[1].mutex，想拿 shard[0].mutex
这种情况下，fatal error 依然会出现，但 goroutine dump 里你会看到两个 goroutine 分别停在不同 shard 的 Lock() 调用上。解决方法不是加更多日志，而是统一加锁顺序：始终按 min(index1, index2) 到 max(index1, index2) 的顺序获取多个 shard 锁。
另外注意：哈希函数 fnv32(key) 输出不稳定（比如 key 包含指针地址或 map 迭代顺序），可能导致相同 key 在不同运行中落到不同 shard，让死锁变成偶发问题——这是最让人头疼的。
