递归内存压力主要来自调用栈过深导致栈溢出和堆上中间数据滞留未释放；需通过深度守卫、调用栈监控、切断闭包引用、复用缓冲区、改用迭代或生成器等方式定位与缓解。
递归处理大数据集时的内存压力，主要来自两块：调用栈持续增长导致栈溢出，以及中间数据（如临时数组、缓存、闭包引用）在堆上累积未释放。问题不是“会不会有压力”，而是“压力从哪来、怎么定位、如何缓解”。
看调用栈是否过深
每次递归调用都会压入一个栈帧，保存参数、局部变量和返回地址。深度超过千层就容易触发栈溢出（如 JavaScript 报 Maximum call stack size exceeded，Java 抛 StackOverflowError）。这不是堆内存不够，而是线程栈空间被填满。
- 加 depth 参数做守卫：入口处检查 if (depth > 500) throw new Error("Too deep")
- 用调试器或语言内置工具查看实际调用深度，比如 Node.js 的 --inspect 配合 Chrome DevTools 的 Call Stack 面板
- 对树/图遍历类递归，预估最大可能深度（如 N 层嵌套目录），设阈值留 20% 余量
查堆上对象是否滞留
栈帧会自动弹出，但函数内创建的对象若被意外持有，就无法被垃圾回收——这是真正的内存泄漏高发区。
- 避免未声明变量：像 res.push(...) 中 res 没用 let/const 声明，它就成了全局变量，永远不释放
- 警惕闭包捕获大对象：排序函数里闭包引用了百万级数组，即使函数执行完，数组也因被引用而存活
- 显式切断引用：递归结束后，把不再需要的大数组、缓存 Map 设为 null 或清空
验临时数据结构是否重复分配
像归并排序中反复 new 数组、递归解析 JSON 时不断拼接字符串，都会快速抬高堆内存峰值。
- 预分配复用缓冲区：把临时数组作为参数传入，而非每次递归都 new —— 如 mergeSort(arr, temp, left, right)
- 用生成器（yield）替代一次性返回全量结果：尤其适合流式处理，内存占用从 O(n) 降到 O(1)
- 对字符串拼接、路径组装等操作，改用 StringBuilder（Java）、StringBuffer（PHP）或数组 push + join（JS）减少中间对象
测是否真需递归
很多场景下，递归只是写法习惯，换成迭代后内存更可控、逻辑更清晰。
- 用显式栈（Stack/Deque）模拟递归：把待处理节点、索引、上下文打包成对象入栈，循环 pop 处理
- 尾递归可转 while 循环：只要递归调用是最后一句，且无后续计算，就能安全改写
- 对用户可控输入（如嵌套配置、自定义模板），强制用迭代——防止恶意构造超深结构击穿服务
