sync.Mutex 不能直接复制，因其内部含系统级状态（如 futex 字段），复制会导致多个副本指向同一内核资源却维护独立 Go 层状态，引发 panic 或锁失效；必须通过指针传递并确保 Lock/Unlock 在同一 goroutine 中成对调用。
为什么 sync.Mutex 不能直接复制？
Go 的 sync.Mutex 是非可复制类型，一旦你把它嵌入结构体后做了值拷贝（比如传参、赋值、切片扩容），运行时可能 panic 或静默失效。这不是 bug，是设计使然——mutex 内部有系统级状态（如 futex 相关字段），复制会让两个副本指向同一内核资源但各自维护独立的 Go 层状态，最终锁行为不可预测。
- 常见错误现象：
fatal error: sync: unlock of unlocked mutex，或看似“没锁住”，多个 goroutine 同时进入临界区 - 典型翻车场景：把含
sync.Mutex的 struct 当作函数参数传值、用append()往结构体切片里加元素、在range循环中取结构体值并调用其带锁方法 - 正确做法：始终传递指针；结构体定义时明确用
*sync.Mutex或更推荐——把sync.Mutex作为匿名字段，并确保所有使用都基于指针接收者
Lock() 和 Unlock() 必须成对出现在同一 goroutine
Go 不支持跨 goroutine 解锁，这和 pthread 或 Java 的 ReentrantLock 都不同。Unlock() 只能由执行过对应 Lock() 的 goroutine 调用，否则直接 panic：sync: unlock of unlocked mutex。这不是延迟或竞态问题，是运行时强制检查。
- 容易踩的坑：在 goroutine 中
Lock()，然后起另一个 goroutine 去Unlock()（比如想做超时释放） - 替代方案：用
sync.Once控制一次性初始化；用context.WithTimeout+select在外层控制流程，但锁的获取和释放仍必须在同一个 goroutine 内完成 - 实用技巧：用
defer mu.Unlock()几乎是铁律，除非你要手动控制解锁时机（如提前释放锁做其他耗时操作）
读多写少场景下，别硬扛 sync.Mutex，换 sync.RWMutex
sync.RWMutex 允许多个 reader 并发，writer 独占。如果你的临界区 80% 以上是读操作（比如查配置、读缓存 map），用它比纯 sync.Mutex 提升明显，且 API 几乎一致。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 注意点：
RUnlock()对应RLock()，Unlock()对应Lock()，混用会 panic - 性能影响：writer 会阻塞后续所有 reader，所以写操作不能太频繁或太慢；如果写占比超过 20%，RWMutex 可能反而更慢（额外状态判断开销）
- 一个典型误用：
RLock()后调Unlock()—— 这不会报错但会导致锁永远无法释放，因为底层状态不匹配
Mutex 不是万能药：哪些情况它根本不管用？
sync.Mutex 只保证「同一进程内」对「内存地址」的互斥访问。它对 channel 发送、文件 I/O、网络请求、数据库事务、外部系统状态等完全无效。
立即学习“go语言免费学习笔记（深入）”；
- 常见误解：给一个
map[string]int加了 mutex，就以为并发安全了 —— 实际上如果这个 map 被逃逸到堆上又被多个 goroutine 通过不同变量名引用，锁保护的是“访问路径”，不是“数据本身” - 真正要保护的，是“共享状态的修改逻辑”，而不是某个变量名。比如并发更新全局计数器，锁的是“读-改-写”三步原子性，不是那个 int 变量本身
- 容易被忽略的点：mutex 不解决 ABA 问题、不提供内存可见性保障之外的语义（Go 的 happens-before 已覆盖这点），也不替代
atomic操作——对单个int64计数，用atomic.AddInt64比加锁轻量得多
