应结合互斥锁、channel、原子操作和context管理来防范数据竞争：写操作用Mutex加锁，读多写少用RWMutex；优先通过channel通信共享内存；简单整数用atomic；用context控制goroutine生命周期。
用互斥锁保护共享变量
当多个 goroutine 同时读写同一个变量时，数据竞争就可能发生。最直接的解决方式是使用 sync.Mutex 或 sync.RWMutex 加锁。写操作必须加互斥锁；若读多写少，可用读写锁提升并发读性能。
- 定义一个结构体，把需要保护的字段和 mutex 封装在一起
- 所有访问该字段的方法内部统一加锁（defer mu.Unlock() 防漏）
- 避免在锁内做耗时操作（如网络请求、大量计算），否则会阻塞其他 goroutine
优先使用通道（channel）传递数据
Golang 的哲学是“不要通过共享内存来通信，而应通过通信来共享内存”。用 channel 在 goroutine 之间传递数据，天然规避了直接读写共享变量的风险。
- 用 chan T 发送/接收值，而不是让多个 goroutine 去改同一个 map 或 slice
- 对需要聚合结果的场景，启动一组 worker goroutine，用 channel 收集返回值
- 注意 channel 容量：无缓冲 channel 会同步阻塞，带缓冲 channel 可缓解压力但不解决逻辑竞争
用 sync/atomic 处理简单整数或指针操作
对于计数器、状态标志（如 running bool）、指针替换等基础类型，sync/atomic 提供了无锁、原子的读写能力，比加锁更轻量。
- 支持 int32/int64/uint32/uint64/uintptr/unsafe.Pointer 类型的原子操作
- 例如：atomic.AddInt64(&counter, 1) 替代 counter++
- 不能用于结构体或 map 等复合类型；也不适用于需要“读-改-写”原子组合逻辑的场景（如 CAS 循环需自行实现）
借助 context 控制生命周期，减少意外并发
数据竞争常源于 goroutine 生命周期失控——比如主流程已退出，后台 goroutine 却还在读写变量。用 context.Context 显式传递取消信号，及时停止无关操作。
- 启动 goroutine 时传入带 cancel 的 context，内部定期 select 检查 Done()
- 关闭 channel 或释放资源前，确保没有 goroutine 正在访问相关数据
- 避免闭包中意外捕获外部变量并异步使用（尤其循环中 i++ 后启动 goroutine，容易全用最后一个 i 值）
基本上就这些。数据安全不是靠某一个技巧，而是结合锁、chan
nel、原子操作和上下文管理，按场景选最合适的组合。不复杂但容易忽略细节。
nel、原子操作和上下文管理，按场景选最合适的组合。不复杂但容易忽略细节。