sync.Locker 接口本身不能直接 new 或实例化
它只是个接口定义，只有 Lock() 和 Unlock() 两个方法。你没法写 var l sync.Locker = new(sync.Locker) —— Go 不允许对接口做 new。真正用的时候，得靠它的实现类型，比如 sync.Mutex 或 sync.RWMutex。
常见错误是试图把 sync.Locker 当成具体锁来传参或初始化，结果编译报错：cannot use sync.Locker (type interface) as type sync.Locker in assignment（看似奇怪但本质是空接口赋值失败）。其实这只是表象，根本原因是没提供具体实现。
- 要用它做函数参数抽象时，传
*sync.Mutex或*sync.RWMutex，它们都实现了sync.Locker - 接口变量可以接收具体锁指针，但反过来不行：不能从
sync.Locker变量“还原”出底层类型，除非用类型断言 - 别在结构体字段里声明
locker sync.Locker然后忘了初始化——它默认是nil，调用Lock()会 panic
用 sync.Locker 抽象锁是为了支持测试替换成 mock 锁
真实场景中，比如一个服务类需要加锁保护状态，但单元测试时不想被真实锁阻塞或干扰并发行为。这时把锁作为依赖注入，类型设为 sync.Locker，测试时就可以传入一个自定义结构体，只记录是否调用了 Lock()/Unlock()，不真正同步。
示例：
type Counter struct {
mu sync.Locker
val int
}
func (c *Counter) Inc() {
c.mu.Lock()
defer c.mu.Unlock()
c.val++
}
测试可传入：type mockLocker struct{ locked bool }
func (m *mockLocker) Lock() { m.locked = true }
func (m *mockLocker) Unlock() { m.locked = false }- 注意 mock 实现必须是指针接收者，否则无法满足接口（值接收者实现的接口，不能用指针赋值）
- 生产代码里传
&sync.Mutex{}，测试里传&mockLocker{}，完全解耦 - 如果锁逻辑带超时、尝试获取等需求，
sync.Locker就不够用了——它不包含TryLock()或上下文支持，得换别的抽象方式
sync.RWMutex 也实现了 sync.Locker，但只暴露了互斥语义
sync.RWMutex 同时实现了 sync.Locker（通过 Lock()/Unlock()）和 sync.RWMutex 自身的 RLock()/RUnlock()。一旦你把它当作 sync.Locker 用，就读不到读锁能力了。
这意味着：
- 如果函数签名只收 sync.Locker，你就只能用写锁模式，哪怕底层是 RWMutex
- 想保留读写区分，就得把接口升级成自定义接口，比如 type RWLocker interface { Locker; RLock(); RUnlock() }
- 这不是设计缺陷，而是接口隔离的代价：用越通用的接口，越拿不到特有功能
- 别为了“统一类型”强行把
RWMutex当Locker传，结果在高读低写的场景下性能反降 - 检查调用方是否真只需要互斥语义——如果只是保护一个计数器，
sync.Mutex更轻量；如果是 map + 频繁读，硬套Locker就丢掉了优化空间 sync.RWMutex的Lock()会阻塞所有新读请求，这点和sync.Mutex表现一致，但容易误以为“反正都是 Locker，没差别”
嵌入 sync.Mutex 时，匿名字段不会自动实现 sync.Locker
有人想省事，在结构体里嵌入 sync.Mutex，然后以为整个结构体就“天然具备锁能力”，甚至直接当 sync.Locker 传——不行。嵌入只是提升方法可见性，接口实现仍需显式满足。
例如：
type Cache struct {
sync.Mutex
data map[string]int
}
这个 Cache 类型本身不实现 sync.Locker，因为接口实现看的是类型方法集，而 Cache 没有声明自己的 Lock() 方法（虽然能调用），Go 规则不允许“继承式接口实现”。- 正确做法是让函数参数接受
*Cache并自己实现Lock()/Unlock()，或者更干脆：传&c.Mutex（取嵌入字段地址） - 如果结构体要对外暴露锁能力，最稳妥是加一个方法返回锁指针：
func (c *Cache) Locker() sync.Locker { return &c.Mutex } - 嵌入在并发安全设计中容易产生错觉，以为“有 Mutex 字段=线程安全”，其实字段访问、方法逻辑仍需人工保证
锁的抽象从来不是为了炫技，而是为了在需要替换、测试或统一调度时少改几行。但每抽一层，就离底层控制远一分——尤其是当 panic 出现在 Unlock() 未配对，或锁粒度突然变大时，接口再干净也救不了逻辑漏洞。
