sync.Mutex 失效主因是值接收者导致锁副本、锁作用域错误或未配对 Unlock；必须用指针接收者，将 Mutex 作为结构体字段与数据同生命周期，并确保 Lock/Unlock 成对。
直接结论：用 sync.Mutex 保护临界区，但必须用指针接收者、defer 解锁、避免复制结构体——否则大概率 panic 或静默失效。
为什么函数参数传值会导致 sync.Mutex 失效
Go 的 sync.Mutex 内部含系统级状态（如 futex 字段），零值可用，但不可复制。一旦你把带 sync.Mutex 的结构体当值传递，就触发了底层状态分裂：
- 原结构体和副本各自维护独立的 Go 层状态，却可能指向同一内核锁资源
- 现象包括：
fatal error: sync: unlock of unlocked mutex，或看似“没加锁”——多个 goroutine 同时进入临界区 - 典型翻车点：
append()往结构体切片里加元素、range循环中取结构体值调用方法、函数参数用值类型接收
Lock() 和 Unlock() 必须在同一个 goroutine 中成对出现
Go 不允许跨 goroutine 解锁，这不是竞态问题，是运行时强制 panic。常见误用：
- 在 goroutine A 中
Lock()，然后起 goroutine B 去Unlock()（比如想做超时释放） - 忘记
defer mu.Unlock()，中间有return或 panic 导致锁未释放，后续所有 goroutine 卡死 - 正确姿势：
mu.Lock()后立刻写defer mu.Unlock()，哪怕你要提前释放锁，也得手动写两次Unlock()+ 新的Lock()，而不是交给另一个 goroutine
读多写少时别硬扛 sync.Mutex，换 sync.RWMutex
如果你的函数 80% 以上只读共享数据（比如查配置、读缓存 map），sync.RWMutex 能显著提升并发吞吐：
立即学习“go语言免费学习笔记（深入）”；
- API 几乎一致：
RLock()/RUnlock()对应读，Lock()/Unlock()对应写 - 混用会 panic：
RLock()后调Unlock()不报错，但锁永远不释放（底层状态不匹配） - 注意写操作代价：
Lock()会阻塞所有新 reader，如果写占比超过 20%，额外判断开销可能让性能反不如纯sync.Mutex
结构体里怎么放 sync.Mutex 才安全
推荐两种写法，本质都是确保锁操作始终作用于同一内存地址：
- 匿名字段 + 指针接收者：
type Cache struct { sync.Mutex data map[string]string } func (c *Cache) Get(key string) string { c.Lock() defer c.Unlock() return c.data[key] } - 显式指针字段：
type Counter struct { mu *sync.Mutex count int } // 初始化时 new(sync.Mutex)，所有方法都用 c.mu.Lock() - 绝对不要：
mu sync.Mutex+ 值接收者方法，或var c Counter直接传参调用
最易被忽略的点：sync.Mutex 的零值可用，但“可用”不等于“可复制”。哪怕你没显式初始化，只要做了值拷贝，就已埋雷。调试时 panic 往往不报行号，而是卡在某个 Unlock() 上——这时候该回头检查结构体是不是被无意传值了。
