绝大多数场景应优先使用 sync.Mutex，仅当读写比稳定高于 8:1（如配置缓存）时才考虑 sync.RWMutex；RWMutex 不支持锁升级，须先 RUnlock 再 Lock；切勿复制锁或跨函数传递锁变量。
读多写少？直接用 sync.RWMutex，否则优先 sync.Mutex
绝大多数场景下，sync.Mutex 是更安全、更直观的选择。它只有一种锁状态，没有读/写语义混淆，也不涉及锁升级降级问题。而 sync.RWMutex 的价值只在「读操作远多于写操作」时才真正体现——比如配置缓存、状态快照、只读元数据查询等。
- 如果读写频率接近（比如 3:1 或 2:1），
RWMutex反而可能因内部 reader 计数和 writer 等待逻辑带来额外开销 - 写操作哪怕只占 5%～10%，但若写请求集中爆发（如批量刷新配置），
RWMutex的写优先策略会阻塞新读请求，导致读延迟毛刺 - 实测表明：当读写比低于 8:1 时，
sync.Mutex在多数负载下吞吐更稳、P99 延迟更低
RWMutex 的 RLock/Lock 不能混用或升级
这是最常踩的坑：试图在持有 RLock 的 goroutine 中直接调用 Lock 升级为写锁——Go 不支持锁升级，这会导致死锁或 panic。
-
RWMutex没有Upgrade()方法，也没有任何隐式转换机制 - 必须先
RUnlock()，再Lock()；反过来，也不能在Lock()后调用RLock() - 更危险的是：在
RLock()保护的函数里调用另一个也用RWMutex的函数，若后者尝试Lock()，就构成嵌套写锁等待，极易死锁
func badUpgrade() {
rwMutex.RLock()
defer rwMutex.RUnlock()
// ❌ 错误：这里无法“升级”，且下面调用会卡住
writeSomething() // 内部调用 rwMutex.Lock()
}
func goodSeparate() {
// 先释放读锁
rwMutex.RUnlock()
// 再获取写锁
rwMutex.Lock()
defer rwMutex.Unlock()
writeSomething()
}
忘记 Unlock 或重复 Unlock 会直接 crash
sync.Mutex 和 sync.RWMutex 都不检测锁持有者，所以一旦出错就是运行时 panic，不是静默错误。
-
Unlock()被遗漏 → 其他 goroutine 永久阻塞在Lock()或RLock()上，程序 hang 死 -
Unlock()被调用两次 → 触发fatal error: sync: unlock of unlocked mutex或sync: RUnlock of unlocked RWMutex - 正确姿势：所有
Lock()/RLock()后必须紧跟defer mu.Unlock()/defer rwmu.RUnlock() - 切勿把锁变量作为参数传入并期望在别处解锁——锁的状态无法跨函数传递
别复制锁，也别在 struct 里嵌套使用未导出锁字段
Go 的 sync.Mutex 和 sync.RWMutex 都包含不可复制的底层字段（如 state int32），一旦被复制（例如作为 struct 字段值拷贝、或传参时按值传递），就会破坏锁一致性，引发未定义行为。
立即学习“go语言免费学习笔记（深入）”；
- 编译器不会报错，但
-race检测能发现 “copy of unlocked mutex” 类警告 - struct 中应将锁声明为指针字段（
*sync.RWMutex）或直接嵌入（sync.RWMutex），但必须确保该 struct 不会被浅拷贝 - 常见反模式：
type Config struct { mu sync.RWMutex; data map[string]string }—— 若 Config 被赋值给另一个变量，mu就被复制了
type SafeConfig struct {
mu sync.RWMutex // ✅ 嵌入合法，但禁止 copy 整个 struct
data map[string]string
}
// ❌ 危险：复制整个 struct 会复制 mu
c1 := SafeConfig{data: make(map[string]string)}
c2 := c1 // mu 被复制！后续 c1.mu 和 c2.mu 完全无关
c1.mu.Lock()
c2.mu.Lock() // 不会阻塞 c1，竞态隐患
真实项目里，锁选型往往不是“理论最优”，而是“最不容易出错+可观测+可调试”。sync.Mutex 的简单性本身就是一种鲁棒性；而 RWMutex 的优势，只在压测确认读写比稳定高于 10:1、且 P99 延迟确实卡在读锁争用上时，才值得引入。 
