go 中 goroutine 并发访问共享变量易出错，因默认无锁且存在读写重排序，导致数据竞争，典型表现为数值异常、计数不准、结构体部分更新；常见错误是在循环中启动 goroutine 并直接引用循环变量。
为什么 go 启动的函数访问共享变量就容易出错
因为 Go 的 goroutine 是轻量级线程，多个 goroutine 可能同时读写同一块内存（比如一个全局 int 变量），而 Go 运行时默认不加锁——只要没显式同步，编译器和 CPU 都可能重排读写顺序，导致中间状态被其他 goroutine 看到。典型表现是：数值“凭空”变小、计数不准、结构体字段部分更新后被读取。
常见错误场景包括：
– 在 for 循环里启动 goroutine 并直接引用循环变量（如 for i := 0; i ，最后很可能全打印 <code>3）
– 多个 goroutine 同时对一个 map 做 insert 或 delete（会 panic 报 fatal error: concurrent map writes）
– 对非原子类型（如 int64、指针、结构体）做无保护的读写
用 sync.Mutex 保护临界区最直接但要注意粒度
加互斥锁是最通用的方案，但关键在“锁什么”和“锁多久”。锁太粗（比如整个函数都包在 mu.Lock()/mu.Unlock() 里）会严重限制并发度；锁太细（比如只锁一行赋值）又可能漏掉依赖逻辑。
实操建议：
– 把需要原子性保证的一组操作包进同一个锁区间，例如“检查是否存在 → 不存在则创建”必须一气呵成，不能分开加锁
– 锁对象尽量小范围，优先锁具体字段或局部结构体，避免锁整个大 struct 或全局变量
– 不要在持有锁时调用可能阻塞或调用回调的函数（比如网络请求、channel 操作），否则会拖慢其他 goroutine
– 使用 defer mu.Unlock() 确保不会因 return 或 panic 忘记释放
立即学习“go语言免费学习笔记（深入）”；
var mu sync.Mutex
var count int
func increment() {
mu.Lock()
defer mu.Unlock()
count++
}
sync/atomic 适合简单整数和指针的无锁操作
当只需要对 int32、int64、uint32、uintptr、unsafe.Pointer 做增减、比较并交换（CAS）、载入或存储时，atomic 包比 Mutex 更轻量，也更安全——它底层依赖 CPU 指令，天然避免竞态。
注意点：
– atomic 不能用于浮点数或结构体（除非你手动转成 uintptr 并确保内存布局稳定）
– 所有读写都必须用 atomic.LoadInt64(&x) / atomic.StoreInt64(&x, v) 等，混用普通赋值会破坏原子性
– atomic.AddInt64 返回新值，atomic.CompareAndSwapInt64 返回是否成功，别忽略返回值
– 在 32 位系统上，对 int64 的非 atomic 操作不是原子的，即使你本地测试没问题，上线也可能崩
channel 不是万能同步工具，但适合“通信胜于共享内存”的场景
Go 官方推荐用 channel 传递数据而非共享内存，但这不等于所有共享状态都要改成 channel。channel 真正擅长的是：事件通知、任务分发、结果收集、限流控制。强行用 channel 模拟计数器或开关，反而增加复杂度和延迟。
实用边界：
– 单生产者 + 单消费者，用无缓冲 channel 实现同步（发送即阻塞，直到对方接收）
– 多 goroutine 需要聚合结果时，用带缓冲 channel 配合 sync.WaitGroup 收集
– 不要用 channel 来保护 map 或 slice 的读写——这比 sync.RWMutex 还难维护
– 注意死锁：没人接收却持续发送，或没人发送却一直 range channel
真正容易被忽略的是：哪怕用了 channel，如果发送的是指针或可变结构体，接收方仍可能和发送方竞争修改同一块内存。要传值，或者确保接收后不再被原 goroutine 修改。
