sync.Mutex 和 sync.RWMutex 不适合高频计数场景，因其锁开销大、多核争抢易触发自旋休眠切换，吞吐仅为 atomic.AddInt64 的 1/5～1/3；RWMutex 在读少写多时更重，且 atomic 无法支持复合操作或条件逻辑，此时需 Mutex 兜底。
为什么 sync.Mutex 和 sync.RWMutex 不适合高频计数场景
因为锁的开销在高并发、高频更新下会成为瓶颈：每次 Lock()/Unlock() 都涉及系统调用或调度器介入，尤其在多核争抢时容易触发自旋+休眠切换。实测中，100 个 goroutine 每秒百万次递增，sync.Mutex 吞吐量可能只有 atomic.AddInt64 的 1/5～1/3。
另外 sync.RWMutex 对写操作无帮助——计数器几乎全是写（Inc），读少写多时它反而比普通互斥锁更重。
- 不要用
RWMutex做纯计数器，读写比例低于 1:10 就不划算 - 避免在 hot path（如 HTTP handler 内部循环）中嵌套锁
- 如果计数器还需支持「重置」或「条件递增」，锁仍是必要兜底，但基础累加优先走原子操作
atomic 包能安全做哪些事？不能做哪些事？
atomic 提供的是底层 CPU 指令级的原子读写与运算，适用于单个整数、指针、unsafe.Pointer 的简单操作。它快、无锁、可伸缩性好，但能力有限：
- ✅ 支持：
atomic.AddInt64、atomic.LoadInt64、atomic.StoreInt64、atomic.CompareAndSwapInt64 - ❌ 不支持：复合操作（如「先读再加再存」非原子）、浮点数（需转整型位模式处理）、结构体字段批量更新
- ⚠️ 注意：
atomic对变量地址有严格要求——必须是 64 位对齐的全局变量或结构体首字段；在 32 位系统上操作int64可能 panic
示例：一个典型安全计数器
type Counter struct {
val int64
}
func (c *Counter) Inc() {
atomic.AddInt64(&c.val, 1)
}
func (c *Counter) Load() int64 {
return atomic.LoadInt64(&c.val)
}
什么时候必须用 sync.Mutex 替代原子操作？
当计数逻辑超出原子指令能力边界时，比如需要「读-改-写」语义、依赖外部状态判断、或维护多个关联字段的一致性。
