竞态条件必须显式检测和修复，go test -race 是唯一可靠的运行时探测手段；它基于TSAN动态插桩，捕获无同步的并发读写，仅用于测试环境，启用后性能下降2–5倍，需用WaitGroup或channel确保goroutine完成后再断言。
Go测试中竞态条件不会自动消失，必须显式检测 + 显式修复；go test -race 是唯一可靠的运行时探测手段，不加它就等于没测并发安全。
用 go test -race 启动竞态检测器
Go 内置的 race detector 是基于动态插桩的 C++ 工具（tsan），它会在编译时注入内存访问跟踪逻辑，运行时捕获“同一地址被不同 goroutine 无同步地读+写”这类冲突。
- 必须加
-race标志，go test默认完全不启用 —— 这不是可选功能，是开关 - 只对
go test生效，go run或go build加-race会报错（需用go run -race） - 启用后二进制体积增大、性能下降 2–5 倍，**仅用于测试环境**，严禁上线
- 检测到竞态时输出含：冲突变量名、读/写 goroutine 的完整调用栈、发生位置（文件:行号）
go test -race -v ./... # 或针对单个测试文件 go test -race -run=TestCounterConcurrent counter_test.go
写并发测试时必须控制 goroutine 生命周期
常见错误是启动 goroutine 后没等它们结束就断言结果，导致 counter 还在被修改，测试结果随机波动，且 -race 可能漏报 —— 因为竞态发生在断言之后。
- 必须用
sync.WaitGroup或channel确保所有并发操作完成后再检查状态 - 避免用
time.Sleep等待，它不可靠、慢、且掩盖真正问题 - 测试应可重复：每次跑都该得到相同结果（比如 1000 次 increment → 结果必须是 1000）
- 如果测试本身 panic 或死锁，
-race不会触发，要先保证测试能跑完
func TestCounterConcurrent(t *testing.T) {
var c Counter
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
wg.Add(1)
go func() {
defer wg.Done()
c.Inc()
}()
}
wg.Wait() // 关键：必须等完再断言
if got := c.Load(); got != 1000 {
t.Errorf("expected 1000, got %d", got)
}
}修复竞态不能只靠加锁，得看场景选对原语
加 sync.Mutex 是最直觉的做法，但不是万能解。锁太重、粒度错、或根本不需要锁，都会引入新问题。
- 纯计数器类整型操作：优先用
sync/atomic，如atomic.AddInt64(&c.val, 1)—— 无锁、快、安全 - 读多写少结构体（如配置缓存）：用
sync.RWMutex，读不用互斥，写才锁 - 复杂状态机或需要串行化逻辑（如订单状态流转）：用
channel把操作委托给单个 goroutine，天然隔离 - 锁必须和数据绑定封装，别让调用方自己记着要 Lock/Unlock —— 容易漏、难维护
type Counter struct {
mu sync.RWMutex
val int64
}
func (c *Counter) Inc() { c.mu.Lock(); defer c.mu.Unlock(); c.val++ }
func (c *Counter) Load() int64 { c.mu.RLock(); defer c.mu.RUnlock(); return c.val }最容易被忽略的一点：竞态检测器只能发现「已执行到的」竞争路径。如果某个临界区在测试中从未被两个 goroutine 同时命中（比如因调度巧合或数据分支未覆盖），-race 就不会报警 —— 所以测试用例要足够“狠”，比如开 100+ goroutine、混入读写、打乱执行节奏，才能把隐藏的竞态逼出来。
