sync.Mutex是零值可用的值类型，声明即初始化；而*sync.Mutex初始为nil，未初始化就调用会panic。
为什么结构体里直接写 mu sync.Mutex 就能用，但改成 *sync.Mutex 就 panic？
因为 sync.Mutex 是零值可用的值类型——内部没有指针、不依赖系统资源，声明即初始化。你写 mu sync.Mutex，它默认就是“未锁定”状态，随时能调 Lock()。
但如果你写成 mu *sync.Mutex，字段初始值是 nil；没手动赋值 &sync.Mutex{} 就调 mu.Lock()，运行时立刻报错：invalid memory address or nil pointer dereference。
- ✅ 正确：结构体字段直接声明为
mu sync.Mutex - ❌ 错误：声明为
mu *sync.Mutex却没初始化 - ⚠️ 特殊情况必须用指针（比如从外部传入锁）？务必检查非
nil：if mu == nil { panic("mutex not initialized") }
defer mu.Unlock() 看似省事，什么情况下反而埋雷？
defer 只在函数返回时执行，一旦临界区逻辑变复杂，就容易失控。最典型的是：提前 return 但忘了放锁，或者 panic 发生在 defer 注册之后、Unlock() 执行之前。
- ❌ 错误模式：
mu.Lock(); if err != nil { return }; defer mu.Unlock()→err非空时锁永远不释放 - ❌ 更危险：
mu.Lock(); json.Unmarshal(data, &v); defer mu.Unlock()→Unmarshalpanic 会导致锁卡死 - ✅ 推荐做法：显式配对，尤其在多分支或可能 panic 的场景：
mu.Lock(); defer func() { mu.Unlock() }()（配合recover太重，不推荐） - ✅ 更干净的解法：把临界区抽成小函数，再用
defer，比如updateValue(func() { c.value++ })
结构体带 sync.Mutex，为什么传值调用就失效？
因为 sync.Mutex 不可复制——它内部有未导出字段（如 state int32），Go 编译器会静默允许赋值，但运行时一旦检测到复制行为（比如结构体赋值、作为 map value、传值参数），就会 panic：sync.Mutex is copied。
立即学习“go语言免费学习笔记（深入）”；
- ❌ 错误示例：
c := Counter{}; go c.Inc()→c被复制，每个 goroutine 操作的是自己副本里的mu，完全没互斥效果 - ❌ 错误示例：
m := make(map[string]Counter); m["a"] = c→ map 赋值触发复制，panic - ✅ 正确姿势：始终用指针：
var c = &Counter{}，方法接收器必须是*Counter，map value 类型设为*Counter - ✅ 上线前必跑：
go vet -copylocks ./，它能捕获 80% 这类低级错误
读多写少时，该不该立刻换 sync.RWMutex？
不该。RWMutex 不是银弹，它只在读操作远多于写操作（比如读:写 > 4:1）、且读逻辑极轻量时才有明显收益；否则，它的额外状态管理开销反而拖慢性能。
- ✅ 适合 RWMutex：
config.Get()（纯读字段）被调用上千次/秒，config.Reload()每分钟最多一次 - ❌ 不适合 RWMutex：
cache.HitCount()和cache.MissCount()频繁交替调用；或读操作本身含 DB 查询、JSON 解析等耗时逻辑 - ⚠️ 致命陷阱：不能在持有
RLock()的 goroutine 中调Lock()，否则死锁 —— 必须先RUnlock()再Lock() - ? 判断依据：先用
-race跑压测，对比go tool pprof中锁等待时间，别凭感觉换
真正难的从来不是怎么加锁，而是判断哪一行数据真正在被并发修改、以及这个锁到底该包多大范围。一个 int 字段配个 sync.Mutex 可能过度，而一个 map[string]*User 只锁整个结构体又常常不够 —— 这些边界，得靠 -race 日志和真实流量说话。
