goland需手动启用-race检测器并配置goroutines面板分析锁争用，高频字段优先用atomic操作，sync.pool不保证线程安全。
启用 -race 检测器必须手动勾选
GoLand 默认不开启竞态检测，即使你写了 go run -race，IDE 里跑的还是普通模式。不勾这个，sync.Mutex 错用、map 并发读写这类问题根本不会报错——它就静默崩溃或返回脏数据。
实操路径：Run → Edit Configurations → 选中你的运行配置 → 勾选 “Enable race detector”。注意：只对当前配置生效，新建配置要重新勾。
- 勾选后启动变慢是正常的，这是为了插入内存访问检查逻辑
- 一旦触发竞态，GoLand 会高亮出错行，并在 Console 输出类似
Read at 0x00c000124000 by goroutine 7的定位信息 - 别在生产环境开它，仅用于本地调试和 CI 流水线中的单元测试阶段
Goroutines 视图里看锁争用热点
断点单步对并发 bug 几乎无效，因为竞态发生在 goroutine 切换瞬间。真正有用的是 Debug 模式下打开 “Goroutines” 面板（默认在右下角 Dock 区），观察哪些 goroutine 卡在 runtime.semasleep 或 sync.runtime_SemacquireMutex。
这些就是锁争用的直接证据。比如 20 个 goroutine 全停在同一个 mu.Lock() 后面，说明这里成了瓶颈。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 点击某个 goroutine 可跳转到它阻塞的具体代码行
- 如果看到大量 goroutine 停在
chan receive，优先检查 channel 容量是否为 0 或接收端没及时消费 - 该视图不依赖 -race，只要进 Debug 模式就会实时刷新
高频字段优先用 atomic 而非 mutex
计数器、开关状态、版本号这类字段，用 sync.Mutex 是过度设计。GoLand 会高亮 atomic.LoadInt64、atomic.StoreUint32 等函数，这是个信号：该用原子操作了。
它们比锁快一个数量级，且无死锁风险。但注意：atomic 只保证单个字段的读写原子性，不能替代结构体整体的并发保护。
- 别对 struct 字段直接用 atomic，先拆成独立变量，或用
atomic.Value包裹指针 -
atomic.AddInt64(&counter, 1)比mu.Lock(); counter++; mu.Unlock()更轻量 - 混用时最容易踩坑：比如结构体里同时有
sync.Map和普通map，后者仍需额外加锁
别把 sync.Pool 当线程安全容器用
sync.Pool 只负责对象复用，不提供任何并发安全保证。常见错误是把它当缓存用：pool.Get().(*MyStruct).Field = val，多个 goroutine 同时 Get 到同一个对象并修改，就会产生数据竞争。
正确姿势是：Get 后当作全新对象初始化，用完 Put 回去前确保所有字段已重置；或者只用它缓存无状态对象（如 bytes.Buffer）。
- GoLand 不会警告这种误用，-race 也检测不到——因为没共享内存访问，只有逻辑错误
- 如果需要线程安全缓存，直接用
sync.Map或带锁封装的 map - Pool 的
New函数必须返回新对象，不能返回全局变量或复用已有实例
