Go无函数调用深度限制，仅受栈空间限制；“爆栈”是栈内存超默认上限（约1GB）导致进程终止，不可recover，且与递归、闭包或defer无关，只取决于栈页累计用量。
Go 没有函数调用深度限制，只有栈空间限制；所谓“爆栈”不是层数超了，而是压栈总内存超了默认上限（约 1GB），且无法 recover。
runtime: goroutine stack exceeds XGB limit 是什么信号
这不是语法错误，也不是 panic 类型可捕获的异常，而是 Go 运行时在检测到当前 goroutine 栈内存分配即将突破硬性阈值（如 1000000000 字节）时主动终止进程。它不区分你是递归、嵌套闭包还是巨量 defer —— 只看栈页累计用量。
- 该 panic 不会进入
recover()流程，defer+recover完全无效 - 错误中显示的字节数（如
1000000000-byte）是运行时估算的栈上限，非精确值，不同 GOOS/GOARCH 下略有浮动 - 实际触发点可能远低于 1GB：初始栈仅 2KB，每次扩容都需 mmap 新页，碎片和对齐开销会让有效可用空间打折扣
为什么 runtime.Caller(skip) 不能用来测递归深度
runtime.Caller 的 skip 是固定偏移量，不是深度探测器。它取的是第 skip + 1 层栈帧，若调用链不够深，ok 直接返回 false，不会报错也不会降级。
- 在深度不确定的中间件里写死
skip = 2，上线后可能因内联或调用路径变化导致日志打不出文件名和行号 - 内联（inlining）会让
runtime.Caller(1)跳过你预期的封装层，直接指向main.main或更上层 - 真要获取当前调用深度，得用
runtime.Callers配合足够大的[]uintptr切片（建议 ≥64），再遍历0..n-1范围解析
怎么安全地测出你的代码真实栈消耗边界
别靠猜，用 pprof 抓真实分配热点。栈内存暴增时，runtime.morestack 和 runtime.newstack 会高频出现在调用链中。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 启动服务时注册 pprof：
import _ "net/http/pprof"，然后http.ListenAndServe(":6060", nil) - 复现可疑路径（如解析 500 层嵌套 JSON），再执行：
go tool pprof http://localhost:6060/debug/pprof/heap - 在 pprof 交互中输入：
top -cum -focus=morestack，若看到大量walkRecursive → runtime.morestack，就是递归失控 - 补测：
go tool pprof -alloc_space，能暴露短命 goroutine 历史栈分配总量，比-inuse_space更敏感
迭代替代递归时最容易漏掉的检查点
把 dfs(node.Left); dfs(node.Right) 改成 stack = append(stack, node.Left, node.Right) 只是第一步。真正容易崩的是图结构或含环路径。
- 栈空判断（
len(stack) == 0）不等于遍历完成，必须加访问标记（如map[*Node]bool）防重复入栈 - 用
[]*Node模拟栈时，避免用值类型（如[]Node）—— 复制大结构体会加速栈/堆膨胀 - 若原递归逻辑含状态传递（如父节点引用、路径前缀），这些状态必须显式存进栈元素，例如：
type frame struct { node *Node; path []string }
最易忽略的是：测试时用平衡树或小数据跑通了，不代表安全。用户可控输入（比如 YAML 模板里 {{ include "x" . | include "x" | include "x" }} 嵌套 200 次）会在压测或上线后才暴露问题。深度参数必须作为接口契约明确定义，而不是藏在实现里靠经验估。
