Go中counter++结果错误、map panic或程序偶尔崩溃，八成是数据竞争；应优先用go run -race main.go检测，它通过插桩监控内存读写，能准确定位竞争点并输出具体行号，但仅在开发测试环境启用。
Go 里出现 counter++ 结果不对、map panic 或者程序偶尔崩溃，八成是数据竞争（Data Race）——不是逻辑错，是并发访问没同步。别猜，先用 -race 跑一遍，90% 的问题当场定位。
用 go run -race 快速暴露竞争点
这是最直接有效的手段，不需要改代码，也不依赖经验判断。它通过插桩监控所有内存读写，一旦发现两个 goroutine 同时读写同一地址且无同步，立刻报 WARNING。
- 命令就是
go run -race main.go，输出会明确标出「Write at … by goroutine X」和「Previous read at … by main goroutine」，连文件行号都给你 - 只在开发/测试环境启用，生产环境禁用——它会让程序慢 2–5 倍，内存开销也翻倍
- 注意：它只能捕获**实际触发的竞争路径**，如果某条竞争路径在本次运行中没走，就不会报。所以要尽量覆盖多并发、多轮次的测试场景
- 常见漏报场景：
time.Sleep不够长导致 goroutine 没真正并发执行；或用sync.WaitGroup但忘了wg.Add，导致主 goroutine 提前退出，竞争根本没机会发生
sync.Mutex 是最通用的兜底方案
当变量被多个 goroutine 读写，又不适合用 channel 重构时，sync.Mutex 就是最稳妥的选择。它的代价清晰，行为确定，不会引入额外的调度复杂度。
- 锁的粒度要小：只包住真正共享的那几行，比如
mu.Lock(); counter++; mu.Unlock()，别把fmt.Println或网络调用塞进临界区 - 务必
defer mu.Unlock()，否则一旦中间 panic，锁就永远卡死 - 不要在锁内调用可能阻塞或重入的函数（比如另一个加了同名锁的函数），否则极易死锁
- 如果读远多于写，换成
sync.RWMutex，用RUnlock和Unlock区分读写释放，能显著提升吞吐
简单计数器优先用 sync/atomic
像 int32、int64、指针这类基础类型，如果只是增减、比较、交换，sync/atomic 比 Mutex 更轻量、无锁、性能高，而且天然避免死锁风险。
立即学习“go语言免费学习笔记（深入）”；
- 把
var counter int改成var counter int64，操作全换成atomic.AddInt64(&counter, 1)、atomic.LoadInt64(&counter) - 注意：原子操作只对单个变量有效，不能用于保护结构体字段或多个变量的组合操作（比如“先读 A 再写 B”这种逻辑）
-
atomic.Value可以安全存取任意类型，适合缓存配置、连接池等只读频繁、更新少的场景，但每次Store都是深拷贝，别往里面塞大对象
用 channel 替代共享变量才是 Go 的惯用法
Go 的设计哲学是 “不要通过共享内存来通信”，意思是：与其让多个 goroutine 去抢一个变量，不如让一个 goroutine 独占该变量，其他 goroutine 通过 channel 发请求。
- 典型模式：启动一个“监控 goroutine”，它内部维护
balance，循环监听depositCh和withdrawCh，只在这里做读写 - 优势明显：无锁、无竞争、逻辑隔离；劣势是多了 goroutine 和 channel 开销，不适合超高频（微秒级）操作
- 容易踩的坑：
select里没加default导致阻塞；channel 容量设为 0 却没配好接收方，一发就 panic；忘记关闭 channel 导致 receiver 永远等下去
真正难处理的从来不是怎么加锁，而是判断“这里到底需不需要同步”。很多竞争藏在初始化逻辑、全局配置加载、甚至 init() 函数里——这些地方看似单线程，但如果有 goroutine 在 main() 之前就启动了，照样会撞上。所以 -race 不仅要跑主流程，还得覆盖 init 阶段和子测试。
