栈溢出错误的关键是快速定位无限递归点，需观察调用栈中重复函数名、检查递归入口与终止条件，并防范setter循环、事件自触发及循环引用等三类高频陷阱。
栈溢出错误（RangeError: Maximum call stack size exceeded）出现时，关键不是立刻重写逻辑，而是快速锁定“谁在不停压栈”。定位的核心是观察调用链特征、识别递归入口、验证终止条件是否生效。
看浏览器控制台的调用栈全貌
错误堆栈里重复出现同一函数名（比如 traverse、clone、set value），且帧数密集堆叠（几十上百层），基本就是递归失控点。注意三点：
- 从最底部（最早调用）往上看，找第一个反复出现的函数——它极可能是递归起点
- 检查该函数是否在自身内部直接或间接调用了自己（包括通过 setter、事件监听器、Promise.then 链等隐式方式）
- 若堆栈中夹杂
Object.defineProperty或set字样，重点排查 setter 内部是否又赋值给同名属性
加深度计数和日志守卫
在疑似递归函数开头插入简易防护，不改逻辑也能暴露问题：
- 增加
depth参数，默认从 0 开始，每次递归 +1 - 开头加判断：
if (depth > 50) console.warn('Deep recursion at', depth, 'in', functionName) - 配合
console.trace()输出当前调用路径，比console.log更清楚上下文
这样运行一次就能看到：是刚进函数就爆了（说明没走终止条件），还是跑到第 1000 层才报错（说明深度真大，需优化结构）。
立即学习“Java免费学习笔记（深入）”；
检查三类高频陷阱入口
多数栈溢出并非算法本身复杂，而是掉进常见逻辑坑：
-
Setter/Getter 循环：如
set name(v) { this.name = v }—— 赋值触发自身，无限循环 - 事件监听器自触发：A 元素监听 click → 执行后手动触发 B.click() → B 的 handler 又触发 A.click()
- 深拷贝或遍历中的循环引用：对象 A 的属性指向 B，B 的属性又指向 A，递归未做已访问标记，就会来回跳
用 debugger 快速中断验证
在递归函数第一行加 debugger，刷新页面后断点会频繁命中。此时：
- 看右侧面板的 “Call Stack”，确认是否逐层加深、无弹出迹象
- 展开每个栈帧，检查参数值是否在收敛（如
n是否变小、node是否走向叶子） - 若某一层参数没变或反而变大（如
n从 5 变成 6），说明终止条件写反或递归参数没更新
不复杂但容易忽略
