直接在结构体字段声明 sync.Mutex 即可用，因其是零值可用的值类型；错误定义为 *sync.Mutex 且未初始化会导致 nil 指针 panic；Lock/Unlock 应显式配对，defer 仅适用于单出口简单临界区；Mutex 不可复制，否则 vet 报错“copies lock value”；RWMutex 仅适用于读多写少场景，否则反而降低性能；应优先采用细粒度锁而非全局大锁。
为什么直接在结构体字段里声明 sync.Mutex 就能用？
因为 sync.Mutex 是值类型，零值可用——它内部没有指针或系统资源句柄，初始化后状态就是“未锁定”。不需要 new(sync.Mutex) 或显式调用构造函数。
常见错误是把它定义成指针字段：*sync.Mutex，然后忘记初始化就调用 Lock()，导致 panic："invalid memory address or nil pointer dereference"。
- 正确写法：
mu sync.Mutex（结构体中直接嵌入） - 错误写法：
mu *sync.Mutex且没赋值&sync.Mutex{} - 如果必须用指针（比如从外部传入），务必确保非 nil
什么时候该用 mu.Lock()/Unlock() 而不是 defer mu.Unlock()？
defer 看似简洁，但在有多个 return 路径、或需要提前释放锁的场景下容易出错。比如在某个条件分支里处理完数据就想放锁，但 defer 会等到函数结束才执行。
典型误用：在 for 循环内用 defer，结果锁在整个函数生命周期都未释放，造成严重阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 推荐在明确的临界区起始处
Lock()，结束处立即Unlock() - 仅当临界区逻辑简单、单入口单出口时，
defer Unlock()才安全 - 更稳妥的做法是把临界区逻辑单独抽出为小函数，再用 defer
为什么 sync.Mutex 不能复制？编译器会报什么错？
sync.Mutex 包含不可拷贝的字段（如 state 和 sema），Go 编译器会在检测到值拷贝时触发 vet 检查：assignment copies lock value to ...。运行时若真复制（比如作为 map 的 value 或结构体赋值），可能导致锁行为异常，甚至死锁。
- 禁止：将含
sync.Mutex的结构体作为 map 的 value，或传给接受值参数的函数 - 正确：始终传递结构体指针；map 的 value 类型应为
*MyStruct而非MyStruct - 检查方式：
go vet ./...，别跳过这步
和 sync.RWMutex 比，什么时候坚持用 sync.Mutex？
sync.RWMutex 并不总是更好。读多写少时它能提升并发读性能，但写操作会阻塞所有读，且其内部实现比 sync.Mutex 更重——尤其在竞争不激烈时，额外开销反而降低吞吐。
- 用
sync.Mutex：临界区极短（如只改一个 int）、读写频率接近、或写操作占主导 - 避免过早优化：不要仅因“可能有并发读”就换 RWMutex，先压测对比
- 注意陷阱：RWMutex 的
RUnlock()若漏调，会导致后续所有RLock()永久阻塞（不像 Mutex 那样 panic 提示）
sync.Mutex 字段，也不要让一个大锁包住整个结构体方法。那不是保护数据，是在制造串行瓶颈。 
