不能直接把 sync.Mutex 传给 goroutine，因为它不是线程安全的复制类型，值传递会导致锁失效、竞态或 panic；正确做法是传递 *sync.Mutex 指针。
为什么不能直接把 sync.Mutex 传给 goroutine
因为 sync.Mutex 不是线程安全的复制类型——它内部包含指针和状态字段，一旦被值传递（比如作为参数传入匿名函数），就可能产生两个 goroutine 操作同一把锁的不同副本，导致锁失效、竞态或 panic。常见错误现象是：看似加了锁，但数据仍被并发修改；或者运行时报 fatal error: sync: Unlock of unlocked mutex。
正确做法永远是传递指针：*sync.Mutex。匿名函数里若需操作锁，必须显式接收或闭包捕获其地址。
- 闭包捕获时，确保捕获的是指针变量（如
mu := &sync.Mutex{}），而非sync.Mutex{}的值 - 如果锁在结构体中，传结构体指针比单独传锁更自然，也避免意外值拷贝
- 不要在匿名函数内重新声明同名锁变量（如
mu := sync.Mutex{}），这会遮蔽外层锁
用闭包绑定锁上下文的典型写法
匿名函数本身不“带”锁，但可以通过闭包捕获外部已声明的锁指针，形成绑定上下文。这种模式适合任务粒度小、锁生命周期与 goroutine 一致的场景（比如单次数据库更新、配置热重载）。
mu := &sync.Mutex{}
data := make(map[string]int)
go func() {
mu.Lock()
defer mu.Unlock()
data["key"] = 42
}()
注意：这里 mu 是闭包变量，不是参数。如果后续需要复用该逻辑，应封装为可复用函数，而不是反复写闭包。
立即学习“go语言免费学习笔记（深入）”；
- 闭包捕获的变量生命周期由 Go 运行时管理，只要 goroutine 还在运行，
mu就不会被回收 - 若闭包同时捕获多个变量（如
mu和data），要确认它们都满足并发安全要求 - 避免在循环中直接启动多个闭包 goroutine 并捕获循环变量（如
for i := range items { go func() { use(i) }() }），i 会被所有 goroutine 共享；应改为go func(i int) { ... }(i)
通过参数传递锁上下文的边界场景
当匿名函数逻辑需被复用、或锁来源不确定（比如来自依赖注入、配置驱动）时，应显式把锁指针作为参数传入，而非依赖闭包。这样更清晰，也便于单元测试。
func updateValue(mu *sync.Mutex, m map[string]int, k string, v int) {
mu.Lock()
defer mu.Unlock()
m[k] = v
}
mu := &sync.Mutex{}
data := make(map[string]int)
go func() {
updateValue(mu, data, "key", 42)
}()
这种写法明确表达了“谁负责加锁”“锁保护哪段数据”，尤其在多人协作或复杂控制流中更可靠。
- 函数签名中锁参数名建议带
Mu或Lock后缀（如mu *sync.Mutex），避免与业务变量混淆 - 不要把锁和数据打包进一个结构体再传值（如
struct{Mu sync.Mutex; Data map[string]int}），值传递会复制Mutex，引发 panic - 若锁来自第三方库（如
redislock），注意其Lock/Unlock是否可重入、是否支持超时，不能假设它行为等同于sync.Mutex
容易被忽略的锁粒度与性能陷阱
匿名函数里加锁不是万能解药。锁范围过大（比如整个 HTTP handler 里只用一把锁）、或锁在高竞争路径上（如高频计数器），会导致 goroutine 大量阻塞，吞吐骤降。这时候“传递锁上下文”只是把问题从一处搬到另一处。
真正关键的是：锁保护的临界区是否最小化？是否可以用无锁结构（如 atomic.Int64）替代？是否该用读写锁（sync.RWMutex）区分读多写少场景？
- 对 map 并发读写，
sync.Map是更轻量的选择，但仅适用于键值对生命周期较长、读远多于写的场景 - 若锁用于保护一组相关操作（如先查后改），考虑用
sync/atomic+ CAS 实现乐观更新，避免阻塞 - 调试时可用
-race检测竞态，但别依赖它发现所有锁设计缺陷——它只报已触发的冲突，不报潜在瓶颈
锁上下文传递本身很简单，难的是判断“该不该锁”“锁多大”“锁多久”。匿名函数只是载体，不是并发问题的终点。
