递归算法重在自然性与可理解性而非必要性；必须设明确base case防爆栈，JS因缺尾调用优化而栈深受限，树遍历等自相似结构才最适用递归。
递归算法不是“必须用递归才能解”的问题，而是“用递归更自然、更易理解”的问题。JavaScript 中能用循环解决的，绝大多数也能用递归，但不意味着该用。
递归函数必须有明确的 base case
没有终止条件的递归会立刻触发 RangeError: Maximum call stack size exceeded。这不是代码写错了，是 JavaScript 引擎强制保护栈空间的结果。
常见错误是把 base case 写成 n === 1 却忘了处理 n === 0 或负数输入；或者在递归调用时没让参数向 base case 靠拢（比如该减 1 却写了加 1）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 先写出最简输入对应的返回值（例如阶乘中
factorial(0)返回1） - 检查每次递归调用的参数是否严格“更小”或“更接近终止状态”
- 对用户输入做前置校验，避免传入
null、undefined或非数字类型导致隐式转换出错
JavaScript 中递归比循环更容易爆栈
V8 引擎（Chrome / Node.js）默认栈深度约 10000–15000 层，但实际能安全使用的远低于此——尤其在嵌套对象深拷贝、DOM 树遍历等场景下，几百层就可能出问题。
这不是算法本身的问题，是 JS 缺乏尾调用优化（TCO）的实际限制：ES2015 规范虽定义了 TCO，但 V8 目前仅在 strict mode + 纯尾调用形式下极有限支持，且已被标记为“暂不优先实现”。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 避免对长度不确定的数组或链表使用朴素递归遍历
- 用迭代替代递归时，可借助
stack数组模拟调用栈（如 DFS） - 若必须递归且数据量大，考虑分治+异步切片（例如用
setTimeout或queueMicrotask拆解任务）
树结构遍历是递归最典型且难以替代的场景
扁平化嵌套菜单、计算 AST 节点数量、序列化带循环引用的对象（需缓存已访问对象）——这些操作天然符合“自相似子结构”的特征，递归比手动维护栈更直观。
示例：简单二叉树节点计数
function countNodes(node) {
if (!node) return 0;
return 1 + countNodes(node.left) + countNodes(node.right);
}
注意这里没有副作用、无状态累积，也不依赖外部变量——这是可读性高的递归的关键特征。一旦混入全局变量或多次修改同一对象，调试难度会指数上升。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 优先使用纯函数式写法：输入确定、无副作用、返回新值
- 深层嵌套对象遍历时，用
WeakMap记录已访问引用，防止无限循环 - 不要为了“看起来高级”而强行递归；如果逻辑上就是线性流程，用
for或reduce更稳妥
真正难的不是写出能跑的递归，是判断什么时候不该用它——尤其是当调用链可能由用户输入长度决定时，栈溢出往往发生在上线后某个边缘请求里。
