sync.Mutex不可复制，因含未导出字段且无拷贝检查器，赋值或传参会panic；须用指针访问、指针接收器方法，并确保Lock/Unlock成对；读多写少场景优先用sync.RWMutex。
为什么直接在结构体里声明 sync.Mutex 就能用，但不能复制？
因为 sync.Mutex 是非可复制类型（unexported fields + no copy checker），一旦被赋值或传参时发生隐式复制，运行时会 panic 并报错 "sync.Mutex is copied"。这不是编译错误，所以容易漏掉。
- 正确做法：始终用指针访问带
sync.Mutex的结构体，比如type Counter Struct { mu sync.Mutex; val int }，然后用&Counter{}初始化 - 错误写法：
c := Counter{}; c2 := c—— 这里c2复制了整个结构体，包含内部的mu，触发检测 - 方法接收器必须是指针：
func (c *Counter) Inc() { c.mu.Lock(); defer c.mu.Unlock(); c.val++ }，否则调用时也会复制
Lock/Unlock 必须成对出现，但 defer 容易掩盖 panic 后的 Unlock
如果 Lock() 后、defer Unlock() 前发生了 panic，而 recover 没处理好，会导致锁永远不释放 —— 典型死锁诱因。
- 常见陷阱：在
defer mu.Unlock()之前调用了可能 panic 的函数（如 jsON 解析、数据库查询） - 稳妥做法：把临界区逻辑包进单独函数，确保 defer 在最外层生效；或用
recover手动兜底（不推荐泛用） - 更安全的替代：考虑用
sync.RWMutex替代纯读场景，或改用sync.Once/ channel 控制初始化类资源
什么时候该用 sync.RWMutex 而不是 sync.Mutex？
当共享资源读多写少（比如配置缓存、状态快照），且读操作本身不修改数据时，sync.RWMutex 能显著提升并发吞吐。
-
RWMutex.RLock()和RUnlock()允许多个 goroutine 同时读 -
RWMutex.Lock()会阻塞所有新读写，等现有读锁全部释放后才获得写权 - 注意：不能在持有读锁时升级为写锁（即 RLock → Lock），会死锁；必须先 RUnlock 再 Lock
- 性能差异明显：100 个 goroutine 并发读，
RWMutex比Mutex快 3–5 倍；但写占比超 20%，优势基本消失
用 go vet 检查锁使用是否规范
go vet 自带 copylocks 检查器，能发现大部分隐式复制问题，但默认不启用，需手动加 flag。
立即学习“go语言免费学习笔记（深入）”；
go vet -copylocks ./...它还会提示：
- 结构体字段含
sync.Mutex却没用指针接收器的方法 - 在 map/slice 中直接存储含 mutex 的结构体（导致扩容或赋值时复制）
- 函数参数接收
sync.Mutex值类型（如func f(m sync.Mutex)）
这个检查不能替代逻辑设计，但能拦住 80% 的低级误用。上线前务必跑一遍。
真正难的是判断“哪些变量需要锁”和“锁粒度是否合理”——比如为单个 int 加锁可能过度，而为整个 map 加锁又可能成为瓶颈。得结合 pprof 看 contention 数据，而不是凭感觉加 mu.Lock()。