go不支持原生可重入锁，因sync.mutex禁止同goroutine重复lock；模拟方案（如栈地址计数、解析stack trace）不可靠且低效；应优先用sync.once处理初始化、rwmutex分离读写或channel状态机实现单goroutine递归控制。
Go 里没有原生 RecursiveMutex，别试图封装 sync.Mutex 实现可重入
Go 的 sync.Mutex 明确不支持同 goroutine 多次 Lock()，否则直接 panic：fatal error: all goroutines are asleep - deadlock 或更隐蔽的死锁（比如第二次 Lock() 永远阻塞）。这不是 bug，是设计选择——Go 鼓励你用更清晰的控制流替代“我正在干啥我再干一遍”的嵌套逻辑。
常见错误现象：有人用 goroutine ID + map 记录持有者来模拟可重入，但 Go 官方不暴露 goroutine ID，任何通过 runtime.Stack 解析字符串提取 ID 的做法都不可靠（格式无保证、开销大、竞态下可能错判），且无法处理 defer 场景。
- 真正需要可重入的场景，大概率是递归调用或回调穿透了同一资源边界，应优先重构为「显式状态管理」或「分层加锁」
- 若必须模拟，可用
sync.RWMutex+map[uintptr]int记录当前 goroutine 的递归深度，但 key 必须用unsafe.Pointer(&someLocalVar)这类唯一栈地址，不能依赖runtime.GoroutineID()（非标准、已废弃） - 性能影响明显：每次 Lock/Unlock 都要原子操作 map、计算栈地址、做 map 查找，比原生
Mutex慢 5–10 倍
获取 Goroutine ID 在 Go 中既没必要也不可行
Go 运行时从不承诺 goroutine ID 的稳定性、可见性或可获取性。所有号称能“安全获取 ID”的第三方包，底层都是解析 runtime.Stack 输出的字符串，例如匹配 goroutine 12345 [running]: —— 但这在 Go 1.22+ 已被证实会因 stack trace 格式微调而失效，且 Stack 本身是昂贵的阻塞操作（需暂停 P）。
- 典型错误：用
fmt.Sprintf("%p", &struct{}{})当 ID —— 这只是栈地址，不同调用可能复用，不是 goroutine 标识 - 真实使用场景极少：日志 trace、调试 hook、某些 profiler 插桩——这些场景应改用
context.Context携带请求 ID，或用go.opentelemetry.io/otel/trace等标准库 - 兼容性风险：Go 主动移除了
runtime.GoroutineID()的实验性支持，未来版本可能让所有 hack 更快失效
替代方案：用 sync.Once 或状态字段避免重复初始化
90% 声称需要可重入锁的代码，实际只是怕「初始化逻辑被并发多次执行」，比如单例构造、lazy config 加载。这时 sync.Once 是正解，它天然幂等、无锁、零开销（首次后直接 return）。
立即学习“go语言免费学习笔记（深入）”；
var once sync.Once
var config *Config
<p>func GetConfig() *Config {
once.Do(func() {
config = loadConfig()
})
return config
}
- 不要把
sync.Once和锁混用：它不保护数据读写，只保「某段代码只执行一次」 - 如果初始化后还要频繁读写共享数据，后续访问用
sync.RWMutex分离读写路径，而不是强行可重入 - 注意：Once 不支持 reset，一旦执行过就不能重试；如有重试需求，得自己用
atomic.Value+ CAS 控制状态
真要可重入？用 channel + 状态机手动控制所有权
极少数场景（如实现自定义调度器、协程库），必须精确控制「谁持锁、重入几次、何时释放」，那就放弃封装 Mutex，改用 channel 显式传递锁权：
type ReentrantLock struct {
owner chan struct{}
counter int
}
<p>func (r *ReentrantLock) Lock() {
select {
case <-r.owner:
r.counter++
default:
r.owner = make(chan struct{}, 1)
r.owner <- struct{}{}
r.counter = 1
}
}</p><p>func (r *ReentrantLock) Unlock() {
r.counter--
if r.counter == 0 {
close(r.owner)
r.owner = nil
}
}
- 这个实现不依赖 goroutine ID，靠 channel 的阻塞语义和计数器保证逻辑正确
- 缺点：无法跨 goroutine 传递锁（channel 关闭后其他 goroutine 无法再 acquire），所以只适用于单 goroutine 内部的递归控制
- 容易踩的坑：忘记检查
r.owner == nil就直接 send，panic；或者 Unlock 过度导致负计数——必须严格配对
可重入的本质矛盾在于：Go 的并发模型假设「锁是 goroutine 间协作的边界」，而可重入模糊了这个边界。越想绕过它，越容易掉进更深的竞态或维护陷阱。
