goland无法单步调试锁本身，只能通过临界区断点、goroutine视图和状态观察验证锁行为；需避免在fmt.errorf等间接调用中触发锁导致死锁。
GoLand 里没法“单步调试锁本身”，只能观察锁生效时的行为
GoLand 的调试器不介入 sync.Mutex 或 sync.RWMutex 的底层实现，它不会在 Lock() 调用处自动暂停、也不会高亮“当前谁持有锁”。你看到的只是普通函数调用——但你可以通过变量状态、goroutine 切换和断点位置，反向验证锁是否按预期起作用。
在临界区前后加断点，配合 goroutine 视图确认串行执行
这是最直接有效的做法。不要只在 Lock() 行设断点，那只会停住获取锁的动作；重点应放在临界区内部和 Unlock() 后。
- 在
c.Lock()下一行（即临界区第一行）设断点，比如c.count++ - 在
defer c.Unlock()所在行之后再设一个断点，确保能观察到锁释放后的状态 - 运行时打开 Debug Tool Window → Goroutines 面板，勾选 “Suspend on breakpoint” 并确认多个 goroutine 是否依次停在此处（而非同时停住）
- 如果两个 goroutine 几乎同时停在第一个断点，说明锁没生效——大概率是用了值拷贝（
Counter{}而非&Counter{}），或锁字段未导出导致不同实例
别在 fmt.Errorf 或 String() 里触发锁，否则会死锁
这是 GoLand 调试中极易复现又难定位的问题：你加了断点，程序卡住，Goroutines 面板显示某个 goroutine 停在 R Lock()，另一个停在 Lock() —— 典型的读写锁嵌套死锁。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 检查所有可能被日志、错误构造、反射（如
fmt.Printf("%+v", x)）间接调用的方法，确认它们是否也用了同一把sync.RWMutex - 典型陷阱：
UpdateDuration()里先Lock()，再fmt.Errorf("... %v", c)，而c.String()又调用了R Lock() - 修复方式不是“在 GoLand 里绕过”，而是重构代码：把校验逻辑（如
duration ）移到锁外；或传入副本（<code>c.copy()）供日志使用
用 -race 编译后再调试，比纯 IDE 更早暴露问题
GoLand 的 debugger 看不到数据竞争，但 go build -race 生成的二进制在运行时一旦检测到并发读写，会立即 panic 并打印堆栈——这比你在断点间反复切 goroutine 更快定位根本原因。
- 在 GoLand 的 Run Configuration 中，把
Build flags设为-race - 启动后若出现
WARNING: DATA RACE，直接跳转到报错行，那里就是锁遗漏或粒度太粗的位置 - 注意：
-race会显著拖慢执行速度，仅用于调试阶段；它和 debugger 可共存，但不要依赖 debugger 单独发现竞态
真正容易被忽略的是：锁的失效往往不在加锁动作本身，而在结构体字段是否被意外复制、方法接收者是否用了值类型、以及任意可能触发方法调用的字符串化操作。GoLand 能帮你停住，但判断“为什么没串行”得靠你盯着 mu 的地址和 goroutine 切换顺序。
