Go不支持递归锁，因sync.Mutex非重入且goroutine ID不可靠；应重构逻辑、用sync.Once或RWMutex替代；需调试时优先用-race和mutexprofile而非记录goroutine ID。
Go 里没有原生 RecursiveMutex，别硬套 pthread 思路
Go 的 sync.Mutex 明确不支持重入——同一个 goroutine 连续两次 Lock() 就会死锁。这不是 bug，是设计选择：Go 鼓励用更清晰的控制流（比如提前 return、拆函数）替代“我在自己代码里再进一次锁”这种隐式依赖。
强行模拟递归锁，容易掩盖设计问题，还可能在 defer 场景下漏 unlock。真需要“可重入语义”，优先考虑：
- 把临界区逻辑抽成无锁函数，由上层统一加锁调用
- 用
sync.Once替代“首次初始化才加锁”的场景 - 改用
sync.RWMutex+ 状态标记，避免嵌套写锁
想记录谁持有了锁？别依赖 goroutine ID
Go 运行时**不提供稳定、可用的 goroutine ID 获取方式**。runtime.Stack() 解析出来的数字只是 debug 信息，不同版本行为不一致；goroutine id 也不是公开 API，任何第三方包（比如 goid）都是靠解析 panic 或 stack trace 字符串实现的，脆弱且开销大。
如果你是为了调试锁竞争或排查死锁：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
go run -race检测数据竞争，比记 goroutine ID 有用得多 - 启用
GODEBUG=mutexprofile=1后跑程序，再用go tool pprof分析锁持有热点 - 在
Lock()/Unlock()前后打日志，用runtime.Caller(1)记位置，比记 goroutine ID 更可靠
非要实现带持有者检查的互斥锁？用 sync.Map + unsafe.Pointer 不如用 map[uintptr]struct{}
有人用 goroutine id 作 key 存 map 来判断是否已持有锁，但 id 不稳定，map 本身又需额外锁保护，反而引入新竞争点。更务实的做法是：用 uintptr 记录当前持有者的栈帧地址（比如 &someLocalVar），配合 sync.Mutex 自身做外层保护：
type RecursiveMutex struct {
mu sync.Mutex
owner uintptr
counter int
}
<p>func (m *RecursiveMutex) Lock() {
me := getGoroutinePtr() // 用 runtime.Caller(0) 取一个稳定地址
m.mu.Lock()
if m.owner == me {
m.counter++
m.mu.Unlock()
return
}
m.owner = me
m.counter = 1
}</p><p>func (m *RecursiveMutex) Unlock() {
m.mu.Lock()
m.counter--
if m.counter == 0 {
m.owner = 0
}
m.mu.Unlock()
}
注意：getGoroutinePtr() 不能返回 goroutine id，只能取当前栈上某个变量地址——它在单次调用中稳定，但跨 goroutine 不可比，所以只适合“本 goroutine 是否已持锁”这种简单判断。
goroutine 调度会让“持有者”概念失效
Go 的 goroutine 可能在任意时刻被抢占、迁移到其他 OS 线程，甚至被暂停很久。你以为“锁还在我手上”，其实调度器早已把它挂起，而你的业务逻辑可能卡在 I/O 或 channel receive 上。这时候去查“谁持有锁”，答案要么过时，要么毫无意义。
真正关键的不是“谁拿的”，而是“为什么拿这么久”：
- 检查临界区内有没有阻塞操作（
time.Sleep、net.Conn.Read、未缓冲 channel send） - 用
pprof/goroutine看锁等待堆栈，定位长持有源头 - 把大锁拆小，按数据边界而非调用边界划分临界区
依赖 goroutine 身份做同步决策，本质上是在对抗 Go 的调度模型。能不动这个念头，就少掉一半坑。
