sync.mutex是值类型互斥锁，非函数；加锁靠lock()方法，必须声明为结构体字段、用指针接收者调用，禁止值传递或局部声明，lock/unlock须成对且粒度最小。
sync.Mutex 不是“互斥锁锁定函数”，它是一个类型；真正执行加锁操作的是 Lock() 方法，解锁是 Unlock() 方法。直接调用 mu.Lock() 就完成了加锁，但是否生效、是否安全，完全取决于你怎么声明和使用它——90% 的锁失效问题，不是没调用 Lock()，而是锁根本没绑定到你要保护的数据上。
为什么 mu.Lock() 看似调用了却没效果
最常见原因是：结构体方法用了值接收者，导致 mu 锁的是副本，原结构体字段毫发无损。
- 错误写法：
func (u User) Update() { u.mu.Lock(); ... }→u是拷贝，u.mu也是新副本，锁了等于没锁 - 正确写法：
func (u *User) Update() { u.mu.Lock(); ... }→ 操作的是原对象的mu字段 - go vet 不报错，
go run -race会暴露 data race，但得你主动加参数运行 - 哪怕结构体只有
name string和mu sync.Mutex两个字段，也必须用指针接收者
sync.Mutex 该声明在哪儿才真正起作用
锁的作用域必须覆盖所有并发访问共享数据的 goroutine，生命周期必须和被保护数据一致。
- ✅ 推荐：作为结构体字段，如
type Counter struct { mu sync.Mutex; val int }—— 锁与数据同生共死，最不容易出错 - ⚠️ 可用但慎用：包级变量
var mu sync.Mutex—— 适合保护全局配置，但易成性能瓶颈，所有并发操作都排队 - ❌ 绝对禁止：函数内声明
var mu sync.Mutex或mu := new(sync.Mutex)—— 每次调用都是新锁，完全不跨 goroutine 生效 - 别把
sync.Mutex当工具函数用，它必须和数据“长在一起”
如何避免 Unlock() 遗漏或 panic 导致死锁
Unlock() 漏掉不会编译报错，但会导致后续所有 goroutine 在 Lock() 处永久阻塞 —— 这是最隐蔽的死锁来源。
- 优先用
defer mu.Unlock()，且必须紧跟在mu.Lock()后面，不能隔行或放在条件分支里 - 错误示范：
mu.Lock(); if err != nil { return }; defer mu.Unlock()→return时defer不执行 - 更稳妥写法：用小作用域包裹，
{ mu.Lock(); defer mu.Unlock(); /* 临界区代码 */ } -
panic时defer仍会执行，所以Lock+defer Unlock是 panic-safe 组合 -
-race能抓 data race，但不报“漏 unlock”，得靠人工审查或静态分析工具辅助
读多写少时别硬套 sync.Mutex，试试 sync.RWMutex
如果结构体 80% 的方法只是读（比如 Get()），只有少数几个改数据（比如 Set()），用 sync.Mutex 让所有 goroutine 串行排队就太浪费了。
-
RWMutex允许多个 goroutine 同时RLock()读，但只要有一个Lock()写，所有新读请求就得排队 - 读操作用
mu.RLock()/mu.RUnlock()，写操作用mu.Lock()/mu.Unlock()—— 不能混用 - 注意：
RUnlock()必须和RLock()成对，漏掉一个，后续所有写操作都会卡住 - 别在持有
RLock()期间调用可能触发写操作的函数（比如回调里改状态），否则极易死锁
真正难的不是记住 Lock() 和 Unlock() 怎么写，而是每次加锁前问一句：这个 mu 字段，是不是真正在保护我眼前这行要读写的变量？它和那个变量，是不是同一个内存地址、同一段生命周期？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
