Go死锁无法用Core Dump分析，因其不触发崩溃、不生成有效快照；应依赖Go原生机制：panic时保存goroutine dump、GODEBUG=schedtrace=1000观测调度状态、go tool trace定位阻塞点，GoLand仅辅助源码跳转。
GoLand 本身不支持直接加载 Core Dump 分析死锁
GoLand 的 Run | Open Core Dump 功能仅适用于 C/C++ 程序生成的标准 ELF core 文件，对 Go 程序无效。Go 运行时崩溃（如 panic）默认不生成 core dump，且即使强制生成（通过 GOTRACEBACK=crash），其内容也不含 goroutine 调度状态、锁持有关系等死锁诊断关键信息——GDB 无法解析 Go 的栈帧与 runtime 结构，info mutex 或 bt 在 Go core 中基本不可用。
死锁根本不会触发 core dump，它压根不 crash
死锁的典型表现是程序静默卡住、CPU 归零、无 panic 输出，此时进程仍处于 S（sleeping）或 R（running）状态，未发送任何终止信号，内核不会自动生成 core 文件。你试图用 core dump 分析死锁，就像拿验尸报告查活人病因——对象错了。
- 真正触发 core dump 的是崩溃类信号：
SIGSEGV、SIGABRT、SIGFPE等 - 死锁触发的是 runtime panic：
fatal error: all goroutines are asleep - deadlock!，它只输出文本堆栈到 stderr，不写内存快照 -
gcore强制抓取挂死进程快照也无效：Go 的 goroutine park 状态在 core 中不可见，GDB 看不到谁在等 channel、谁持有了sync.Mutex
该用什么替代方案定位 Go 死锁
必须放弃 core dump 思路，转向 Go 原生可观测性机制：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 加
GODEBUG=schedtrace=1000启动程序，每秒打印调度器摘要，观察gomaxprocs、runqueue是否归零、goroutines数是否停滞 - 遇到死锁 panic 时，**立刻保存终端完整输出**——其中的 goroutine dump 是唯一权威现场，重点关注标着
semacquire、chan receive、runtime.gopark的栈帧及其调用链 - 在疑似锁操作前后插入
log.Printf("lock %p at %s", &mu, debug.PrintStack())，确认Unlock()是否执行（尤其注意多return分支漏 defer） - 用
go tool trace记录运行时事件：go run -gcflags="-l" main.go && go tool trace trace.out，在浏览器中查看 goroutine 阻塞点和锁竞争
GoLand 能帮上忙的唯一环节
GoLand 对死锁分析的实用价值仅限于：在你拿到 runtime 打印的 goroutine dump 文本后，用它快速跳转到 dump 中提到的源码行（比如 main.go:42），并高亮显示对应 mu.Lock()、ch <- 或 wg.Wait() 语句。它不能自动推导锁依赖环，也不能跨 goroutine 关联持有/等待关系——这部分必须靠你手动对照多个栈帧，画出资源等待图。
最容易被忽略的是：死锁 dump 里出现的 created by 行，它指向 goroutine 的启动点，而非阻塞点；真正要盯的是 goroutine N [chan send]: 后面那一长串调用栈，那里藏着没被接收的 channel 发送或没被释放的 mutex。
