goland递归检测仅静态标记语法递归，不反映运行时真实调用深度；需用runtime.caller循环抓取栈帧、funcforpc解析函数名、缩进可视化层级，并配合环境变量开关与深度阈值控制。
为什么不能直接用 GoLand 的“递归检测”功能做深度追踪
GoLand 装订区域标出递归调用，只是静态语法分析结果，它不运行代码、不感知 depth 参数变化、也不记录每次调用时的实际栈深。你看到的“递归标记”和 runtime 中真实发生的调用层级完全脱钩——比如一个函数被标记为递归，但实际运行中可能因条件提前返回，根本没进第二层；也可能用户输入导致深度飙到 50 层，IDE 却毫无反应。
在递归函数入口加 runtime.Caller 循环打印是最轻量的实操方案
别依赖 debug.PrintStack() 或 IDE 自带的“Evaluate Expression”动态查栈——前者开销大且阻塞调度器，后者在 goroutine 切换后就失效。真要看到每一层谁调了谁、深度多少、在哪一行，就得自己抓：
- 在递归函数第一行写 for 循环，从
i = 1开始调runtime.Caller(i)，直到返回false - 每次拿到
pc后，用runtime.FuncForPC(pc).Name()提取完整函数名（如"main.parseJSON"），避免只靠文件行号误判同名函数 - 用缩进表示深度：
strings.Repeat(" ", i-1) + funcName，比纯数字 depth 更直观反映调用关系 - 注意：不要在 hot path（如 HTTP handler 内部）无条件开启，建议用环境变量开关，例如
if os.Getenv("TRACE_RECURSION") != ""
用 defer + 时间戳打点比单纯看调用栈更实用
光知道“谁调了谁”不够，你还得知道“哪一层卡住了”。Go 里最简方式是：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 在递归函数开头加
start := time.Now() - 结尾加
defer fmt.Printf("[depth=%d] %s took %v\n", depth, runtime.FuncForPC(reflect.ValueOf(f).Pointer()).Name(), time.Since(start)) - 注意：
reflect.ValueOf(f).Pointer()是获取当前函数指针的安全方式，比硬编码函数名更可靠 - 如果函数签名不固定（比如闭包或方法值），改用
runtime.Caller(0)拿当前帧再解析，但记得跳过runtime.Caller自身那一层
深度不可控时，必须用切片模拟栈并手动计数
当递归由用户输入驱动（如解析嵌套 YAML、展开模板 include），靠函数参数传 depth 已经不够用了——你没法在 panic 发生前拦截。这时候得放弃递归写法：
- 把“当前待处理节点 + 当前深度”打包成结构体，压入
[]task切片 - 每次
pop时检查len(stack) > maxDepth，超限直接return errors.New("recursion too deep") - 这样做的好处是：深度判断在用户态，recover 可捕获；栈大小可控；还能在每轮循环里插入日志、采样、限流
- GoLand 调试器对这种切片栈支持更好——你可以直接在 Variables 面板里展开
stack看当前所有待执行任务
真正难的不是打出调用路径，而是区分哪些深度是合法业务需要、哪些是恶意构造。runtime.Caller 循环能帮你确认“发生了什么”，但要不要拦、拦在哪一层，得结合协议规范（比如 HTTP 头最大嵌套 5 层）和配置项来定，不能只看数字。
