rwmutex仅在读占比≥80%、写极少且非“读-改-写”时才优于mutex；否则mutex更稳、更轻、无写饥饿风险，且误用rwmutex易致性能下降或死锁。
sync.Mutex 和 sync.RWMutex 不是“选哪个更好”的问题，而是“用错锁类型会导致性能浪费或死锁”的问题。绝大多数竞态不是因为没加锁，而是锁的范围、粒度或类型用错了。
为什么 sync.Mutex 不能直接替换成 sync.RWMutex
很多人看到“读多写少”就立刻换 RWMutex，结果反而更慢甚至卡死。根本原因是：RWMutex 的读锁不阻塞其他读锁，但写锁会阻塞所有读锁和写锁；而 Mutex 是完全互斥的。
- 如果你的临界区里混着读+写（比如先查 map 再删 key），用
RWMutex的RUnlock()后再Lock()就可能被其他 goroutine 插入读操作，导致逻辑错乱 -
RWMutex的写锁获取优先级高于读锁——一旦有 goroutine 在等写锁，新进来的读请求会被阻塞，直到写锁释放。这在高写压场景下会让读操作集体饥饿 -
RWMutex占用内存略大（多一个readerCount字段），且加读锁开销略高于Mutex加锁（需原子增减 reader 计数）
defer mutex.Unlock() 不是万能保险
用 defer 确实能防忘记解锁，但它救不了以下三种典型错误：
- 在加锁后 panic：如果临界区里触发 panic，
defer会执行，但若 panic 被 recover 捕获后继续执行，后续又调用Lock()，就会死锁（同一个 goroutine 重复加锁） - 锁跨函数传递：把
*sync.Mutex当参数传给多个函数，每个函数都Lock()/Unlock()，极易出现解锁次数多于加锁次数，或某个分支漏掉Unlock() - 锁被嵌套在循环里：比如 for 循环内反复
Lock()/Unlock()，实际等于没锁——每次加锁只保护单次迭代，无法保证整个批量操作的原子性
什么时候必须用 sync.RWMutex 而不是 sync.Mutex
只有当满足全部三个条件时，RWMutex 才值得引入：
- 读操作占比 > 80%，且单次读耗时明显（比如 JSON 解析、结构体字段深拷贝）
- 写操作极少发生，且写操作本身不依赖当前读结果（即不能是“读-改-写”模式）
- 你明确控制了写操作的串行化路径——例如所有写都走同一个 channel 或统一的更新 goroutine，而不是分散在多个地方直接调
Lock()
常见误用：给一个频繁更新的配置 struct 加 RWMutex，但每个 handler 都自己 RLock() → xxx.field → RUnlock()，结果写操作一来，几十个正在读的 goroutine 全部卡住。
锁粒度太粗是并发性能的最大杀手
把整张 map 包进一个 Mutex 里，和给每个 key 分配独立锁，吞吐量可能差 10 倍以上。但别盲目拆——锁太多会增加调度开销和内存占用。
- 对 slice 或 map 做高频读写时，优先考虑用
sync.Map（仅适用于键值对缓存场景，不支持遍历） - 若必须用普通 map，可按 key 哈希分片，每片配一个
Mutex（例如 32 个桶，mu[key%32]） - 结构体字段级锁要谨慎：如果两个字段从不同时访问，分开锁没问题；但如果常一起读写（如
user.Name和user.Email），拆锁反而增加维护成本
真正难的不是写锁，而是判断“哪些数据必须被同一把锁保护”。这个边界一旦划错，后面所有优化都是徒劳。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
