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