goland 默认不启用竞态检测，需手动配置 -race；sync.map 并非更安全而是更省心但有代价；调试时默认只显示当前 goroutine 堆栈。
为什么 go run 没报错，但线上却出现数据竞争？
GoLand 本身不自动执行 go run -race，静态检查也覆盖不了运行时的竞态逻辑。你写的 sync.Mutex 看似加锁了，但只要漏掉一次 mu.Lock() 或多调了一次 mu.Unlock()，或者在 defer 里写错顺序，Race Detector 就会在运行时爆出来——而 GoLand 默认不会帮你跑这个检测。
实操建议：
- 在 GoLand 的 Run Configuration 中勾选
-race（路径：Edit Configurations → Program arguments → 输入-race） - 别依赖 IDE 的“绿色小钩”判断线程安全；
go vet和staticcheck插件可装，但它们对竞态的检出率远低于-race - 所有涉及共享变量读写的测试用例，必须用
go test -race运行，不是只点绿色三角形
sync.Map 真的比普通 map + sync.RWMutex 更安全吗？
不是更“安全”，是更“省心但有代价”。sync.Map 对高频读、低频写的场景做了优化，但它不支持遍历（range）、不保证迭代一致性，且内部用了冗余存储和原子操作，内存开销更大。
实操建议：
- 如果需要
range或保证读取时看到“某一时刻快照”，老老实实用map+sync.RWMutex -
sync.Map.LoadOrStore是原子的，但sync.Map.Range不是——它回调函数执行期间，其他 goroutine 仍可修改 map，所以结果可能不一致 - GoLand 的代码补全会提示
sync.Map方法，但不会提醒你“这里用普通 map 加锁更合适”，得自己判断场景
GoLand 调试并发问题时，为什么看不到 goroutine 堆栈？
默认调试器只显示当前 goroutine，其他正在休眠或阻塞的 goroutine 堆栈被隐藏。你断点停在 select 或 ch 上，却找不到谁在另一端收消息，是因为 GoLand 没展开 goroutine 视图。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
实操建议：
- 调试时点击右上角 Debug Tool Window → 左侧切换到
Goroutines标签页（不是 Threads） - 按
Ctrl+Shift+F8（macOS 是Cmd+Shift+F8）打开 Breakpoints 设置，勾选Suspend: All，这样断点触发时所有 goroutine 都暂停，方便排查死锁 - 如果看到大量
runtime.gopark堆栈，说明 goroutine 卡在 channel、mutex 或 timer 上，重点查 channel 是否已 close、mutex 是否被遗忘 unlock
怎么让 GoLand 提前发现 context.WithCancel 泄漏？
context.WithCancel 返回的 cancel 函数没被调用，会导致 goroutine 和其子 context 永远无法回收。GoLand 不会静态分析 control flow 到 cancel 调用，但可以靠配置和习惯规避。
实操建议：
- 始终用
defer cancel()，且放在WithCancel调用之后紧邻行——GoLand 的代码格式化和检查能识别这种模式 - 避免在闭包里传入未 defer 的
cancel；如果必须传递，命名变量为safeCancel并加注释说明生命周期 - 启用 GoLand 的
Go > Inspection > Unused parameter和Unreachable code，有时能间接暴露 cancel 被忽略的分支
并发安全不是靠某个工具兜底，而是每处 channel 操作、每次 mutex 使用、每个 context 创建，都要明确谁负责关闭、谁负责释放、谁可能阻塞。GoLand 只能帮你看到 goroutine、标出 race、补全方法名，剩下的得盯住自己的代码逻辑。
