递归性能差异源于js引擎栈管理策略不同：chrome（v8）约13500层、firefox（spidermonkey）4000–7000层、safari（javascriptcore）20000–25000层；实际深度受参数大小、响应式操作等影响，生产环境应限制同步递归深度不超过1000层并优先采用迭代或微任务拆解。
递归性能在不同浏览器中差异明显，核心原因不是代码本身，而是底层 JavaScript 引擎对调用栈的管理策略不同。Chrome、Firefox、Safari 使用的引擎（V8、SpiderMonkey、JavaScriptCore）在栈空间分配、优化逻辑和调试干预上各有侧重，直接导致同一段递归代码在各浏览器中能跑的深度、耗时甚至是否崩溃都可能完全不同。
引擎栈容量是硬边界
递归深度受限于函数调用栈的可用空间，这个空间由引擎在启动时预设，并随运行环境浮动：
- Chrome（V8）：通常支持约 13,500 层，但开启 DevTools 后可能下降 10%–20%，因调试钩子额外占用栈帧
- Firefox（SpiderMonkey）：更保守，一般仅 4,000–7,000 层，对栈使用控制严格，稳定性优先
- Safari（JavaScriptCore）：栈空间最宽松，实测可达 20,000–25,000 层，尤其在 macOS 上表现更稳
参数与上下文放大差异
实际递归深度远不止“层数”数字，还受每次调用携带的数据量影响：
- 传入大数组、长字符串或闭包会显著增加单帧内存开销，Chrome 可能剩 8,000 层，Firefox 可能只剩 2,000 层
- 严格模式对栈结构影响微弱，不可作为跨浏览器兼容依据
- 若递归函数内嵌套 Promise 回调、事件监听或 Vue 响应式赋值（如 修改 ref 对象触发 Proxy 追踪），会快速耗尽栈空间，Firefox 尤其敏感
执行效率不只看深度
慢不只是卡在栈溢出，还有执行过程中的隐性开销：
- 每次递归调用需压入返回地址、形参、局部变量、上下文环境，这些操作在 V8 中优化较好，但在 SpiderMonkey 中开销更明显
- 没有尾调用优化（TCO）支持的引擎（目前所有主流浏览器均未默认启用）会让每层调用都累积中间状态，时间复杂度和空间复杂度同步上升
- DevTools 开启时，Chrome 会注入额外追踪逻辑，不仅减深度，还会拖慢单次调用速度
别依赖“能跑通”来判断安全
一段在 Safari 跑 2 万层没问题的递归，在 Firefox 上可能刚过 5,000 层就报 RangeError；看似正常的代码，在 Vue 或 React 的响应式环境中可能触发指数级代理访问，瞬间卡死。
- 生产环境应避免深度超过 1,000 层的同步递归
- 优先改用迭代（while / for）、分治+队列、或微任务拆解（queueMicrotask）缓解栈压力
- 对不确定数据规模的场景（如解析无限嵌套菜单、树形结构扁平化），务必加深度阈值和降级逻辑
