sync.rwmutex仅在读多写少时优于sync.mutex；rlock/runlock必须成对且及时释放，否则导致静默死锁；读锁内禁止重操作，不可升级为写锁，混用或误导出会破坏并发安全。
sync.RWMutex 不是“只要用了就读写分离”，它只在读多写少时才比 sync.Mutex 有优势；用错场景或写法，反而拖慢性能、引发死锁。
RLock() 和 RUnlock() 必须成对出现，且不能靠“逻辑上应该会执行”来保证
Go 不检查你是否漏掉 RUnlock()，也不会 panic，但后续所有新来的 RLock() 和 Lock() 都会被卡住——这是静默死锁。
- 错误写法：在 if 分支里提前 return 却没 unlock
- 危险写法：把
defer mu.RUnlock()放在mu.RLock()之前（defer 在函数入口就注册，但锁还没拿到） - 安全写法：拿到读锁后立刻写
defer mu.RUnlock()，哪怕后面有多个 return 路径
写操作会等所有当前读锁释放，但不中断正在执行的读逻辑
这是 sync.RWMutex 的关键语义：它不会强制终止已获得 RLock() 的 goroutine，而是等它们自己跑完并调用 RUnlock()。所以读锁里做重操作 = 变相阻塞写操作。
- ❌ 错误：在
RLock()后直接调用耗时函数（如json.Marshal、遍历大 map、HTTP 请求） - ✅ 正确：只做轻量拷贝（如
dataCopy := append([]int(nil), data...)），然后RUnlock()，再处理 - 注意：如果读操作平均耗时 100ms，而写操作每 50ms 触发一次，写请求将严重排队
Lock() 和 Unlock() 与 RLock()/RUnlock() 不能混用同一把锁实例
sync.RWMutex 的写锁和读锁是同一把锁的两种模式，不是两把独立锁。一个 goroutine 持有 RLock() 时，另一个 goroutine 调用 Lock() 就会阻塞；反之，持有 Lock() 时，所有 RLock() 也会阻塞。
- 没有“读锁升级为写锁”的机制——必须先
RUnlock()，再Lock()，中间存在竞态窗口 - 不要在一个函数里
RLock()，在另一个函数里RUnlock()；锁的生命周期必须在同一作用域内闭环 - 结构体嵌入
sync.RWMutex时，别导出它（如mu sync.RWMutex），避免外部误调用Lock()破坏读写约定
读多写少才值得用 RWMutex，否则不如 Mutex
当读写比例接近 1:1 或写更频繁时，sync.RWMutex 内部维护读计数器、唤醒队列等开销反而高于 sync.Mutex，实测可能慢 10%–20%。
- 典型适用场景：配置缓存（
map[string]interface{}）、路由表、连接池状态快照 - 不适用场景：高频更新的计数器、实时聚合指标、消息队列消费者位点
- 验证方法：用
go test -bench对比两种锁在真实负载下的吞吐和 p99 延迟，别凭感觉选
copy()、一次 len()、甚至一次 fmt.Sprintf()，都可能让写操作等上几十毫秒。锁不是贴膏药，得清楚它保护的边界在哪，以及谁在等它。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
