Go 的 sync.Mutex 不支持递归加锁，当同一 goroutine 多次调用 Lock() 时会永久阻塞；解决该问题的关键是重构代码，将临界区逻辑与锁管理分离，确保每个方法只在必要时持锁，并通过无锁的内部函数复用核心逻辑。
go 的 `sync.mutex` 不支持递归加锁，当同一 goroutine 多次调用 `lock()` 时会永久阻塞；解决该问题的关键是重构代码，将临界区逻辑与锁管理分离，确保每个方法只在必要时持锁，并通过无锁的内部函数复用核心逻辑。
在 Go 并发编程中，sync.Mutex 是保障结构体字段线程安全的常用手段。但其设计遵循“非重入”原则：同一个 goroutine 再次调用 Lock() 时不会成功，而是无限等待——这并非 bug，而是有意为之的安全约束。因此，当多个公开方法（如 A() 和 B()）各自独立加锁，且存在调用链（如 A() → B()）时，极易触发死锁。
✅ 正确做法：分离「锁边界」与「业务逻辑」
核心原则是：锁的粒度应严格限定在数据访问入口处，所有共享状态操作应下沉为不持锁的私有方法。以下为重构示例：
type Thing struct {
mu sync.Mutex
data int
}
// ✅ 公共方法：负责加锁 + 调用无锁逻辑
func (t *Thing) A() {
t.mu.Lock()
defer t.mu.Unlock()
t.foo()
t.b() // 直接调用无锁版本，避免二次加锁
}
func (t *Thing) B() {
t.mu.Lock()
defer t.mu.Unlock()
t.b() // 复用相同逻辑，无需重复加锁
}
// ✅ 私有方法：纯业务逻辑，不操作 mutex
func (t *Thing) foo() { /* 修改 t.data 等 */ }
func (t *Thing) b() { t.bar() }
func (t *Thing) bar() { /* 其他临界操作 */ }⚠️ 注意事项
- 禁止暴露带锁逻辑给其他方法调用：所有 Lock()/Unlock() 必须成对出现在同一函数作用域内（推荐 defer），且不得跨方法传递锁状态。
- 警惕隐式调用链：检查 defer 中的函数、回调、接口方法调用是否可能间接触发另一把锁。
-
替代方案需谨慎评估：
- sync.RWMutex 可缓解读多写少场景，但不解决递归加锁；
- sync.Once 仅适用于一次性初始化；
- 第三方递归锁（如 github.com/juju/errors 的 Mutex）违背 Go 的简洁哲学，且易掩盖设计缺陷，不推荐。
? 总结
Go 中不存在“安全的递归锁”，这不是语言缺陷，而是对并发模型的主动约束。真正的最佳实践是：通过清晰的职责划分，让锁成为方法的“守门人”，而非嵌入逻辑流程中。每一次 Lock() 都应对应一个明确的数据保护边界；而所有可复用的临界操作，都应剥离为无锁的私有方法。这种设计不仅规避死锁，还提升了可测试性与可维护性。
