递归栈溢出主因是调用栈无休止增长，解决需补全终止条件、加深度防护、改迭代实现或临时调栈大小；核心在逻辑控制而非扩容内存。
递归函数导致栈溢出，核心原因是调用栈被无休止或过深地填充，超出了运行时环境的栈空间上限。这不是内存不够，而是“压栈停不下来”。解决它要从逻辑控制入手，而不是加内存。
补全并验证终止条件
这是最常见也最容易忽略的根源。很多爆栈不是因为递归太深，而是根本没出口。
- 检查每个递归分支：是否所有路径都覆盖了明确的 base case？比如 n == 0、n < 0、node == null、list.isEmpty()
- 警惕边界穿透：例如写 if (n == 1) 却传入 n = -3，条件跳过，直接进下一层递归
- 在递归调用前做空值/有效性校验：比如 process(node.left) 前先判 node.left != null，避免空指针后仍触发无效递归
加入深度防护机制
即使有终止条件，恶意输入或极端结构（如千层链表、深度嵌套 JSON）仍可能绕过逻辑判断。主动设限是安全兜底。
- 为递归函数增加 depth 参数，每次调用时 depth + 1
- 开头加守卫语句：if (depth > 500) throw new Error("Recursion too deep")
- 阈值参考：普通业务建议 ≤ 500；已知树高不超过 100 层的，设 200 更稳妥
改用迭代实现（推荐用于生产环境）
把隐式依赖系统栈的递归，转为显式用堆内存管理状态的循环。这是真正规避栈限制的治本方式。
- 用 Stack、Deque 或数组模拟调用栈，存入待处理节点、索引或上下文对象
- 循环中 pop() 取出一个任务，处理完后将子任务 push() 进栈
- 例如二叉树中序遍历：递归版在 1000 层就可能崩，迭代版轻松处理万层树
临时调整栈大小（仅作排查或过渡）
这不是修复，而是帮你争取时间定位问题。它掩盖缺陷，不能替代代码优化。
- Java：启动加 -Xss2m（单线程栈设为 2MB）
- C/C++：Linux 下运行前执行 ulimit -s 16384（单位 KB），Windows 可链接时指定栈大小
- Node.js：启动参数 --stack-size=4096（单位 KB）
- 注意：增大栈会挤压其他线程资源，多线程服务慎用；且无法突破 OS 硬限制（如 Windows 默认 1MB）
