Go中sync.Mutex必须与被保护数据同生命周期且仅通过指针访问；值接收者、局部声明、漏Unlock任一都会导致锁失效，推荐将Mutex定义为结构体字段。
Go 里加 sync.Mutex 不是调个 Lock() 就完事——锁必须和被保护的数据绑定在同一生命周期内，且只能通过指针访问。值接收者、局部声明、漏 Unlock()，三者任一都会让锁彻底失效。
为什么 func (u User) UpdateName() 里的 u.mu.Lock() 没用
值接收者会拷贝整个结构体，u 是副本，u.mu 也是副本。锁这个临时对象对原 User 实例零影响。
- 必须改用指针接收者：
func (u *User) UpdateName(name string) -
go vet不报这种错，得人工检查接收者类型 - 哪怕结构体只有两个字段，也别图省事写成值接收者
sync.Mutex 该定义在结构体字段、包变量还是函数里
锁的作用域必须覆盖所有可能并发访问共享数据的 goroutine。
- ✅ 推荐：作为结构体字段（如
type Counter struct { mu sync.Mutex; val int }），锁与数据同生命周期，最不容易出错 - ⚠️ 可用但需谨慎：包级
var mu sync.Mutex，适合保护全局变量，但易成性能瓶颈 - ❌ 绝对禁止：在函数内部声明
var mu sync.Mutex，每次调用都是新锁，无法跨 goroutine 生效
如何避免 Unlock() 遗漏或 panic 导致死锁
sync.Mutex 不支持重入，未配对 Unlock() 会让后续 goroutine 永久阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 优先用
defer mu.Unlock()，但必须紧跟在mu.Lock()后面，不能隔行或放在条件分支里 - 多个提前返回点？用小作用域包住：
{ mu.Lock(); defer mu.Unlock(); /* work */ } -
go run -race能检测竞态，但不报“漏 unlock”，得靠代码审查或静态分析工具辅助
读多写少时该用 sync.Mutex 还是 sync.RWMutex
用 sync.Mutex 会让所有 goroutine（包括只读）排队；sync.RWMutex 允许多个读并发，写仍独占。
- 读操作用
RLock()/RUnlock()，写操作用Lock()/Unlock()，不能混用 - 如果读操作占比超 70%，切换到
RWMutex通常能提升吞吐量 - 但
RWMutex内部开销略高，读写比例不明显时反而更慢
最容易被忽略的是锁和数据的绑定关系——不是“加了锁就安全”，而是“锁是否真正在保护你认为它在保护的那个变量”。结构体字段方式最不容易出错，其他方式都要反复确认作用域和生命周期是否对齐。
