goland调试多协程需主动打开debug窗口的goroutines标签页查看所有协程id、状态及执行位置，刚启动时仅显示main协程，待调度后其他协程才出现；须确保编译启用-gcflags="all=-n -l"保留调试信息。
GoLand 调试多协程代码，关键不是“能不能断点”，而是你得看得到哪些协程在跑、在哪卡住、谁没结束——dlv 是底层引擎，GoLand 只是界面，真正起作用的是调试器对 goroutine 状态的暴露能力。
如何在 GoLand 里看到所有活跃协程
默认断点只停当前 goroutine，其他协程照常运行，容易误判逻辑。必须主动打开协程视图：
- 启动调试后，点击右下角 Debug 工具窗口 → Goroutines 标签页（不是 Threads）
- 这里列出所有 goroutine ID、状态（running / waiting / syscall / chan receive 等）、当前执行位置（文件+行号）
- 点击某一行可切换到该 goroutine 的调用栈，
dlv会自动 attach 并展示其 stack trace - 注意：刚启动时可能只显示 main goroutine，等其他协程真正调度起来（比如遇到
time.Sleep或 channel 操作）才会出现在列表中
断点打在 goroutine 函数里却没命中？检查编译参数
GoLand 默认构建参数可能剥离了调试信息，导致 dlv 找不到符号：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 进 Run → Edit Configurations → Go Build，勾选 “Use custom build tags”，并在 Build flags 中填入：
-gcflags="all=-N -l" - 确保没有加
-ldflags="-s -w"—— 这两个 flag 会删掉符号表和调试信息，dlv就无法识别函数名和行号 - 验证方法：终端执行
file your_binary，输出含not stripped才算成功
WaitGroup 阻塞时怎么定位哪个 goroutine 没 Done
sync.WaitGroup 卡死是最常见的多协程调试痛点，靠猜不行：
- 在
wg.Wait()行设断点，暂停后立刻切到 Goroutines 视图 - 筛选状态为
chan receive或select的 goroutine，它们大概率卡在defer wg.Done()前面（比如 panic 了、提前 return、或 channel send 阻塞） - 逐个点开可疑 goroutine 的 stack trace，重点看是否漏了
defer wg.Done()，或是否在 if 分支里条件性调用了wg.Done() - 如果 goroutine 列表里根本看不到对应任务，说明它根本没启动——检查
wg.Add(1)是否写在go func() { ... }()之后（顺序反了）
channel 死锁时别只看 panic 提示
Go 运行时报 fatal error: all goroutines are asleep - deadlock 是结果，不是原因：
- 调试时先禁用 “Auto resume after panic”，让程序停在 panic 前一刻（GoLand → Settings → Build → Debugger → Go → uncheck “Resume on panic”）
- 此时再看 Goroutines 视图：所有 goroutine 状态应全是
chan send或chan receive，没有 running - 逐个 inspect 每个 goroutine 的 channel 操作目标（比如
ch 或 <code>），确认 channel 是否已 close、容量是否为 0、是否有 goroutine 在等另一端 - 特别注意：用
range ch的 goroutine 如果 channel 没 close，它会永远等待；而 sender 如果没被接收，也会卡住
最易被忽略的点：GoLand 的 Goroutines 视图依赖 dlv 的实时采样，不是全量快照。如果某个 goroutine 执行极快（比如纯计算没 IO），它可能一闪而过，根本不会出现在列表里——这时候得靠日志打点或加 runtime.Gosched() 强制让出，才能把它“钉”在视图中。
