Go并发安全必须通过-go test -race测试暴露竞态，结合WaitGroup高概率触发竞争、atomic/Mutex修复后确保-race静默，并用goleak检查goroutine泄漏。
Go语言的并发安全性不能靠肉眼判断，必须通过有针对性的单元测试来暴露竞态条件。核心方法是结合 -race 竞态检测器 + 可重复触发的并发操作 + 显式同步控制。
用 -race 启动竞态检测是前提
Go 自带的 race detector 是发现数据竞争最直接有效的工具。它不是可选插件，而是必须开启的测试基础：
- 运行测试时加上
go test -race，所有go run或go build也应加-race做临时验证 - 注意：开启后程序会变慢、内存占用升高，仅用于测试环境，不可用于生产构建
- 一旦检测到竞争，会打印出读/写发生在哪一行、哪个 goroutine，信息非常具体，直接定位问题源头
构造高概率触发竞争的并发测试场景
单纯起几个 goroutine 调用函数往往不够。要让竞争“大概率发生”，需主动制造临界区压力：
- 用
sync.WaitGroup控制多个 goroutine 同时（或快速连续）访问共享变量或方法 - 循环多次（比如 100–1000 次），增加调度不确定性带来的碰撞机会
- 避免在 goroutine 内部加 sleep 或 channel 等人为同步——这反而会掩盖问题
- 示例：测试一个计数器
Inc()方法，启动 10 个 goroutine 各自调用 100 次，最后检查总数是否为 1000
用 sync/atomic 或 sync.Mutex 修复后，测试必须能通过 -race
修复不等于“看起来不 panic”——必须确保 -race 完全静默：
立即学习“go语言免费学习笔记（深入）”；
- 优先用
atomic（如atomic.AddInt64）处理简单数值操作，性能好且无锁 - 涉及多字段更新、条件判断或复杂逻辑时，用
sync.Mutex或sync.RWMutex包裹临界区 - 切忌只加锁但没覆盖全部读写路径（比如忘了对读操作加锁），测试会再次报 race
- 修复后重新跑
go test -race，零警告才算真正安全
补充：用 go.uber.org/goleak 检查 goroutine 泄漏
并发测试常伴随 goroutine 忘记结束，导致资源堆积。这不是数据竞争，但属于并发缺陷：
- 在测试函数前后调用
goleak.VerifyNone(t)，自动检查是否有意外存活的 goroutine - 特别适合测试含 channel、timer、后台 worker 的代码
- 和
-race配合使用，构成并发健壮性的双重保障
基本上就这些。不复杂但容易忽略的是：别只写“能跑通”的测试，要写“能让 race detector 报警”的测试——那才是并发安全的试金石。
