javascript调用栈无统一标准限制，实际深度由引擎实现与内存资源决定：chrome约13500层、firefox4000–7000层、safari20000–25000层、node.js默认8000–12000层；压测应采用二分试探法结合try/catch定位临界值，并同步验证depth≤1000的守卫逻辑是否有效拦截。
JavaScript调用栈没有统一标准限制，实际深度由引擎实现和内存资源决定，不是固定数字，而是浮动的物理上限。
Chrome（V8）实测安全深度约 13,500 层，但会因参数大小、闭包数量、是否开启 DevTools 或内存压力明显下降，低至 11,000 层以下；
Firefox（SpiderMonkey）较保守，通常在 4,000–7,000 层；
Safari（JavaScriptCore）最宽松，可达 20,000–25,000 层；
Node.js 默认栈空间约 1MB，对应递归深度约 8,000–12,000 层，可通过 --stack-size=16384 扩展至 16MB，但不建议盲目加大。
真正影响深度的不是“调用了多少次”，而是每个栈帧占用的空间：参数越多、局部变量越大、作用域链越深，单层消耗越高，总层数就越少。
怎么进行压测？
直接跑满调用栈不是为了“破纪录”，而是为了验证代码在临界深度下的行为是否可控。压测重点不在极限值本身，而在防御机制是否生效。
用二分试探法快速定位当前环境临界值
写一个带 try/catch 的递归函数，用二分搜索逼近崩溃点：
- 起始范围设为 [1000, 50000]
- 每次取中点调用，捕获
RangeError: Maximum call stack size exceeded - 根据是否报错缩小区间，10–15 轮即可收敛到较准数值
- 注意：同一环境多次运行结果可能波动，需取多次最小值作为安全参考
压测时必须同步验证防护逻辑
不能只测“崩在哪”，更要测“崩之前有没有拦住”：
- 在递归入口加 depth 参数，阈值设为 1000，超限时 throw 自定义错误（如
'Recursion depth exceeded'） - 确保该错误能被捕获，且不触发栈溢出
- 验证降级路径是否可用（比如切换为显式栈遍历）
模拟真实压力场景
单纯空递归测不出问题，要贴近实际：
- 传入大对象或深层嵌套结构（如 10 层嵌套的 JSON）
- 在严格模式下运行（部分引擎栈开销略增）
- 开启 Chrome DevTools 后重测（实测会压缩可用深度 10%–15%）
- Node.js 环境下搭配
--inspect启动，观察 V8 内存与栈使用变化
避免无效压测
- 不要用
setTimeout或Promise包裹递归——这已脱离调用栈模型，测的是事件循环，不是栈深度 - 不依赖尾递归优化（TCO）做压测基准，因仅 Safari 默认支持，Chrome/Firefox 实际未启用
- 不反复执行单次超深递归，容易触发引擎保护机制或系统级内存限制
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
