goland不支持线程断点，仅支持goroutine断点；需通过edit breakpoint设置condition，如runtime.goid() == 42或ctx.value("trace_id") == "req-abc123"，并在临界区前后而非mu.lock()内部设断点。

GoLand 本身不提供“线程级”调试能力，因为 Go 没有 OS 线程调度概念；它能真正用起来的，是基于 goroutine 的断点过滤、状态观察和运行时诊断配合——直接设断点在 mu.Lock() 上基本无效，得换思路。

怎么让断点只在目标 goroutine 里触发

GoLand 的断点默认对所有 goroutine 生效，但并发调试时你通常只关心某一个（比如处理某个 trace_id 的请求）。关键不是“加断点”，而是“限条件”：

• 右键断点 → Edit Breakpoint → 勾选 Condition
• 输入表达式，例如：runtime.GoID() == 42（需先在日志里打一次 runtime.GoID() 定位 ID）
• 或更稳妥的业务标识：ctx.Value("trace_id") == "req-abc123"（前提是 ctx 已注入）
• 避免用 strings.Contains(debug.Stack(), "...")：每次触发都 dump 全栈，性能开销大，容易卡死调试器

为什么在 mu.Lock() 和 mu.Unlock() 上设断点总跳过

因为 sync.Mutex 底层是汇编+原子指令实现的，没有 Go 源码行号映射，Delve 无法在函数体内停住。这不是 IDE 问题，是 Go 运行时设计使然。

GoLand 2026.1.1

GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。

下载

• 别试图在 Lock() 调用行打断点——它大概率被跳过
• 真要观察锁行为，改在临界区前后设断点：mu.Lock() **之前** 和 mu.Unlock() **之后** 是有效的
• 或者直接用 go tool trace 的 Synchronization 视图看 mutex wait 条形图，比断点更直观

线上服务卡住时怎么快速定位 goroutine 状态

别重启，用 dlv attach 动态诊断——只要二进制没 strip（即没加 -ldflags="-s -w"），就能看到实时 goroutine 栈：

• 查 PID：ps aux | grep your_binary
• attach：dlv attach <pid></pid>
• 进 dlv 后执行：goroutines（列出全部 goroutine 及状态）
• 挑一个可疑的：goroutine <id> bt</id> 看完整调用栈
• 注意：若程序用了 CGO_ENABLED=0 编译，仍可 attach；但 musl 或静态链接到嵌入式环境可能失败

别依赖 GoLand 自带 Profiler 查锁竞争

GoLand 的「Profiler」按钮默认只抓 CPU/heap，mutex profile 需手动触发且必须提前开启采样——否则 trace.out 里根本没同步事件。

• 代码里加：runtime.SetMutexProfileFraction(1)（开发期用，生产建议设为 5）
• 启动时加参数：-trace=trace.out，并确保 runtime/trace.Start() 已调用
• 查竞争别只看 pprof：先跑 go tool trace trace.out，进 Web 界面点 Synchronization，拖时间轴看 mutex wait 密度和高度
• 想量化秒级等待？得自己埋点：start := time.Now(); mu.Lock(); log.Printf("LOCK_WAIT_MS=%d", time.Since(start).Milliseconds())

最易忽略的一点：goroutine ID（runtime.GoID()）每次进程重启都会变，不能写死在配置或脚本里；它只适合单次调试会话中临时定位。