无法用 reflect 获取递归深度，因 reflect 不涉及执行上下文；应显式传参、goroutine 局部计数或 runtime.caller 配合帧解析，避免全局 map 和高频栈采样。
怎么用 reflect 拿到函数调用栈的递归深度
Go 的 reflect 包本身不提供调用栈或递归深度信息——它只管类型和值，不管执行上下文。想动态追踪函数是否在递归中、当前嵌套几层，得绕开 reflect，改用 runtime.Caller 或 debug.PrintStack 配合手动计数。
常见错误是试图从 reflect.Value 里“挖出”调用层数，比如对 reflect.ValueOf(fn).Call(...) 做文章，结果发现返回值和参数都干净利落，完全没附带任何执行痕迹。
- 真正能用的路径只有：在函数入口处主动记录深度，比如用
map[*runtime.Func]int缓存每个函数地址的当前调用次数 - 或者每次进入函数时调用
runtime.Caller(1)解析 PC，再用runtime.FuncForPC找到函数名，自己维护一个全局 map 计数 - 注意：
runtime.Caller开销不小，别在 hot path 上高频调用；生产环境建议用编译期标记（如结构体字段）替代运行时探测
runtime.Caller 怎么安全解析递归层级
直接靠 runtime.Caller(n) 往上翻帧，数到哪个 PC 对应自己函数，就能算出当前递归深度。但要注意：优化开启（-gcflags="-l" 关闭内联）会影响帧可见性，内联后某些调用会消失，导致深度计算偏小。
示例逻辑：
立即学习“go语言免费学习笔记（深入）”；
func depth() int {
pc := make([]uintptr, 50)
n := runtime.Callers(2, pc) // 跳过 depth 和上层包装
count := 0
for i := 0; i < n; i++ {
f := runtime.FuncForPC(pc[i])
if f != nil && strings.Contains(f.Name(), "myPackage.myFunc") {
count++
}
}
return count
}
- 别依赖固定层数（比如总查
Caller(2)），要用Callers拿一整段栈，再遍历匹配函数名或包路径 -
FuncForPC可能返回 nil（比如调用发生在代码未导出或 CGO 边界），必须判空 - 函数名匹配推荐用
strings.HasSuffix(f.Name(), "/myFunc")，避免包重名冲突
为什么不用 debug.Stack() 做深度判断
debug.Stack() 返回的是完整字符串栈迹，解析起来又慢又脆——正则一写错就漏层，而且每调用一次都触发一次 goroutine 栈 dump，性能杀伤极大，压测时容易让 QPS 断崖下跌。
- 仅适合调试打印，绝不能进业务逻辑分支（比如
if depth > 3 { log.Fatal(...) }） - 字符串解析无法区分同名方法（如不同 struct 的
String()），也搞不定匿名函数 - 如果真要日志化递归路径，建议用
runtime.CallersFrames+ 迭代器，比字符串切分稳定得多
goroutine 局部深度计数比全局 map 更靠谱
用全局 map 存 funcPtr → depth 看似简单，但并发调用时 race 风险高，加锁又拖慢；更糟的是，多个 goroutine 同时调同一个函数，会互相污染深度值。
正确做法是把深度存在 goroutine 本地：用 context.WithValue 传一个 depthKey，或者更轻量地，用 sync.Map 配合 goroutine id（虽然 Go 不暴露 ID，但可用 unsafe.Pointer(&someLocalVar) 作临时标识）。
- 推荐方案：入口函数接收一个可选
depth int参数，默认 0，递归调用时显式传depth + 1—— 简单、无共享、无反射、零额外依赖 - 如果必须隐藏参数，可用
ctx.Value，但记得用自定义 type 做 key，别用string防止 key 冲突 - 所有基于反射或运行时栈的方案，本质都是“事后补救”，而显式传参才是 Go 风格的清晰控制流
递归深度不是类型系统能描述的东西，Go 的静态特性决定了这事没法靠 reflect “自动感知”。越想让它智能，越容易掉进栈帧不可靠、内联干扰、并发污染这些坑里。显式传参或 goroutine 局部状态，才是可控的起点。
