直接嵌入sync.Locker接口容易出错，因为它是纯抽象接口，无实现且不可实例化；必须由具体类型（如*sync.Mutex）实现其Lock()和Unlock()方法，否则编译失败或运行时panic。
为什么直接嵌入 sync.Locker 接口反而容易出错
因为 sync.Locker 本身只是个接口（含 Lock() 和 Unlock() 两个方法），它不提供任何实现——你不能 new 出一个 sync.Locker，也不能直接调用它的方法。常见错误是试图这么写：var l sync.Locker = sync.Mutex{}，这会编译失败：结构体字面量不能隐式转换为接口类型（除非显式赋值给接口变量）。真正该做的是让自定义类型 *实现* 这个接口。
怎么让自定义结构体满足 sync.Locker 合约
只要你的类型有签名完全匹配的 Lock() 和 Unlock() 方法（接收者必须是指针），Go 就自动认定它实现了 sync.Locker。不需要显式声明 implements 或类似语法。
- 接收者必须是指针类型，否则无法修改内部状态（比如底层
sync.Mutex的 locked 标志） - 方法签名必须严格一致：
func (m *MyLock) Lock()、func (m *MyLock) Unlock()，不能多参数、不能返回值 - 通常内部组合一个
sync.Mutex或sync.RWMutex，复用其成熟实现，而不是自己手写锁逻辑
示例：
type MyResourceLock struct {
mu sync.Mutex
// 可额外加字段，比如 ownerID、acquireTime 等用于审计
}
<p>func (m *MyResourceLock) Lock() {
m.mu.Lock()
}</p><p>func (m *MyResourceLock) Unlock() {
m.mu.Unlock()
}</p><p>// 使用时：
var lock MyResourceLock
lock.Lock()
defer lock.Unlock()
// …操作共享资源
在资源管理中嵌入 sync.Locker 时要注意什么
如果你设计一个资源句柄类型（比如 DBConnection 或 FileHandle），想让它天然支持锁语义，可以把 sync.Locker 作为匿名字段嵌入——但得小心字段名冲突和方法覆盖。
立即学习“go语言免费学习笔记（深入）”；
- 嵌入
sync.Mutex是安全且常见的；嵌入sync.Locker接口则毫无意义（接口不能嵌入，只能实现） - 如果同时嵌入多个带
Lock()/Unlock()的类型，会触发方法冲突编译错误 - 更推荐显式组合 + 实现接口，而非依赖匿名字段“自动提升”，这样语义清晰、调试方便
- 注意：
sync.Mutex不可复制，所以包含它的结构体也必须按指针传递；若忘记取地址，运行时 panic 会提示"sync.Mutex is copied"
什么时候不该用自定义 sync.Locker 实现
绝大多数场景下，直接用 sync.Mutex 或 sync.RWMutex 更简单可靠。只有当你需要在加锁/解锁前后注入可观测行为（如日志、指标、超时检测）或强制约束使用模式（如要求必须配对 defer）时，才值得封装。
- 不要为了“看起来更面向对象”而封装——Go 鼓励组合而非继承，
sync.Mutex本身就是最佳实践 - 避免在
Lock()里做耗时操作（如网络请求、磁盘 I/O），否则会阻塞其他 goroutine - 如果资源本身已带锁（如
*sql.DB的Query方法内部已线程安全），再套一层锁可能多余甚至引发死锁
真正关键的不是“能不能写”，而是“有没有必要写”。多数人卡在第一步：把接口当类型用，结果连编译都过不了。
