Go递归栈溢出panic无法recover，因发生在运行时底层，早于panic机制；必须显式传depth参数校验或改用切片模拟栈迭代，禁用defer/recover及SetMaxStack等伪解法。
Go里递归死循环引发的栈溢出panic无法recover，必须从设计上掐断——不是调参数、不是加defer，而是显式传depth参数并校验，或直接改用切片模拟栈迭代。
为什么recover()对栈溢出完全无效
这类panic发生在Go运行时底层（runtime: goroutine stack exceeds 1000000000-byte limit），早于Go的panic机制。即使你在递归外层包了defer func() { recover() }()，程序照样崩溃，控制台连recover日志都不会打印。
- 实测：在深度递归函数外加
defer recover，panic仍直接终止进程 -
runtime/debug.SetMaxStack()只影响新goroutine初始栈上限，和递归深度无关；调小它反而会让合法的大局部变量分配失败 - Java的
-Xss、C的栈保护机制，在Go中不存在对应概念
怎么写才不会栈爆：所有递归入口必须带depth参数
这不是可选项，是硬性约束。用户输入、配置嵌套、JSON结构、模板include等任何可能被外部控制的递归路径，都必须显式校验深度。
- 初始调用传
0，每次递归传depth + 1 - 第一行就写
if depth > maxDepth { return errors.New("recursion too deep") } -
maxDepth不能写死为100：HTTP头嵌套建议≤5，YAML!include建议≤8，这些要写进常量注释或配置项 - 终止条件必须可达：
if n 比<code>if n == 0更安全，避免负数输入导致无限递归
比递归更稳的解法：用[]*Node模拟调用栈
当嵌套深度不可控（比如解析用户上传的JSON、AST遍历、路径展开），迭代比递归可靠得多。切片模拟栈能实时监控长度、避免栈帧累积、也更容易加限流和超时。
立即学习“go语言免费学习笔记（深入）”；
- 预分配容量：
stack := make([]*TreeNode, 0, 1024)，减少扩容开销 - 入栈前判空：
if node != nil { stack = append(stack, node) }，防nil指针压栈后死循环 - 实时限深：
if len(stack) > maxDepth { return errors.New("stack too deep") }，比函数参数更直观 - 别用channel模拟栈——容易忘记
close()导致goroutine泄漏，反而掩盖问题
容易被忽略的细节：归并排序、树遍历里的mid计算陷阱
很多“看起来像递归但实际无限”的崩溃，根源不在深度限制，而在逻辑错误。例如归并排序里写错区间分割，会导致同一子数组反复入栈：
- 错误写法：
mid := len(slice) / 2→ 总是基于原切片长度，子区间不变 - 正确写法：
mid := first + (last - first) / 2，配合if first >= last { return } - 树遍历中
curr = curr.Right后没判nil就进下一轮循环，会漏节点甚至触发空指针panic - json.Unmarshal里用
json.RawMessage延迟解析深层字段，比硬递归安全得多
真正难的不是写个depth++，而是在每个可能被攻击者操控的入口点，都记得加这一行判断，并且把maxDepth设得合理——它既不能太松（放行恶意嵌套），也不能太紧（误杀正常业务）。这需要结合协议规范、业务语义和线上观测数据来定，不是靠试出来的。
