goland虽不直接报栈溢出，但可通过call hierarchy定位深层递归、pprof分析栈分配热点、evaluate expression监控递归深度、迭代栈显式限深等手段提前发现并防范栈失控问题。
GoLand 本身不直接报“栈溢出”，因为 Go 运行时不会抛 stack overflow panic；但如果你在调试或压测中观察到进程 RSS 暴涨、卡顿、OOM 或出现 runtime: goroutine stack exceeds 1GB limit 错误，那大概率是深层调用（尤其是递归）失控了。关键不是等崩溃，而是提前从调用链里揪出深度异常点。
用 GoLand 的「Call Hierarchy」定位可疑递归入口
静态分析调用深度比等 runtime 崩溃更早发现问题。右键函数名 → Find Usages 不够，要选 Call Hierarchy（快捷键 Ctrl+Alt+H / Cmd+Option+H）：
• 展开后重点关注：同一函数在调用链中反复出现（如 parseExpr → parseExpr → parseExpr）；
• 若某路径下嵌套层数 > 20，且参数未明显收敛（如 depth 未递减、字符串未截断），就是高危信号；
• 特别留意 JSON/YAML 解析、模板渲染、AST 遍历等易被用户输入驱动的函数——它们常被忽略 depth 校验。
配合 pprof 在 GoLand 内启动 HTTP pprof 并抓栈分配热点
GoLand 支持直接运行带 pprof 的服务，无需手敲命令：
• 在 Run Configuration 中勾选 Enable HTTP pprof（或手动加 import _ "net/http/pprof" + http.ListenAndServe(":6060", nil)）；
• 启动后访问 http://localhost:6060/debug/pprof/heap，下载 heap.pb.gz；
• 在 GoLand 的 Tools → Analyze Memory Dump 中打开该文件，切换到 Allocation Stack Traces 标签页；
• 搜索 runtime.morestack 或 runtime.newstack，看哪些业务函数（如 walkNode）反复触发栈扩容；
• 注意：若 StackInuse 占 heap 总量 > 30%，且集中在少数几个函数，基本可锁定问题源头。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
调试时用「Evaluate Expression」实时监控递归深度
单纯设断点不够，需量化深度：
• 在递归函数入口处打断点；
• 在 Evaluate Expression（Alt+F8）中输入类似 len(debug.Stack()) / 1024（粗略估算当前栈帧字节数）或直接观察传入的 depth 参数值；
• 更稳妥的做法：在函数开头加临时日志 log.Printf("depth=%d, caller=%s", depth, runtime.Caller(1))，并用 GoLand 的 Console Filter 按 depth= 筛选；
• 如果发现 depth 超过预设阈值（如 YAML include ≤ 8 层）却仍在增长，说明终止条件失效或参数未正确传递。
别信「goroutine 数量少就安全」——切片模拟栈也得限深
有人把递归改成迭代后以为万事大吉，结果在 []*Node 上疯狂 append，导致内存耗尽：
• 在迭代逻辑中，显式检查栈长度：if len(stack) > maxDepth { return errors.New("exceeded max depth") }；
• maxDepth 必须按场景设（HTTP 头嵌套 ≤ 5，路径展开 ≤ 16），不能统一硬编码为 100；
• GoLand 的 Code Inspection 不会提醒这个，得靠人工 Review 或写单元测试覆盖边界输入；
• 若用 channel 模拟栈，务必配 sync.WaitGroup 和 close(ch)，否则 goroutine 泄漏会掩盖真正的栈问题。
depth 的解析器被嵌套在另一个没校验的模板引擎里，两层叠加就突破阈值。这种链式失控，在 GoLand 里单靠静态分析看不到，必须结合 pprof 分配轨迹和运行时 depth 监控交叉验证。
