不能靠基本数据类型占栈空间小支撑深度递归；应改用显式栈+状态机实现可控迭代，配合输入校验、中间值截断与快照回滚，确保数学计算强安全、可中断、可审计。
直接说结论：不能靠“基本数据类型占栈空间小”来支撑极高频率 + 深度嵌套递归计算。这不是优化方向，而是认知误区——强行这么做，大概率触发 RangeError: Maximum call stack size exceeded，模型还没跑就崩了。
真正可行的实战路径，是用栈空间优势做“控制流管理”，把深度递归逻辑平滑转为受控迭代，同时保障数学语义不变、边界清晰、可中断、可审计。下面分三块讲清楚：
栈空间小 ≠ 能堆深递归
基本类型（如 number、boolean）在调用栈中确实只占 8 字节左右，比对象引用轻得多。但栈安全不取决于单帧大小，而取决于总帧数上限（V8 默认约 10k–15k 层）。
哪怕每层只压入 depth: number 和 x: number 两个变量，超 12000 层照样溢出。
更关键的是：高频调用下，函数调用开销（帧创建/销毁、参数拷贝、作用域链维护）会成为瓶颈，不是内存，是 CPU 和上下文切换成本。
把“栈优势”用在刀刃上：显式栈 + 状态机
放弃隐式递归调用栈，改用一个数组模拟栈，每个元素只存必要状态（纯基本类型），例如：
function safeCompute(expr) {
const stack = [{ type: 'expr', node: expr, depth: 0 }];
const result = [];
while (stack.length > 0) {
const { type, node, depth } = stack.pop();
if (depth > MAX_SAFE_DEPTH) {
throw new Error(`Depth limit ${MAX_SAFE_DEPTH} exceeded`);
}
if (type === 'expr' && isLeaf(node)) {
result.push(evaluateLeaf(node));
continue;
}
if (type === 'expr') {
// 反向压入子节点，保持原递归顺序
for (let i = node.children.length - 1; i >= 0; i--) {
stack.push({ type: 'expr', node: node.children[i], depth: depth + 1 });
}
continue;
}
}
return combineResults(result);
}
✅ 优势：
- 所有栈元素都是 plain object，字段全为基本类型，无闭包、无 this、无原型链
- 深度可控、可记录、可日志采样（比如每 1000 层打点）
- 出错时能精确返回
depth和node.id，方便定位数学表达式哪一环异常
数学模型强安全的三个硬约束，必须靠栈外机制兜底
仅靠栈操作无法满足“强安全”，需组合以下设计：
-
确定性输入校验前置
在进栈前完成：- 表达式 AST 深度预检（非运行时，用静态遍历）
- 所有数值范围检查（如
x ∈ [-1e6, 1e6]，防Math.exp(1000)类爆炸） - 运算符白名单（禁用
eval、Function、with相关动态行为）
-
中间值截断与饱和处理
不依赖 JavaScript 的Infinity或NaN向上传播，而是在每步计算后主动判断：function clampNumber(v) { if (!isFinite(v)) return v > 0 ? MAX_VALUE : MIN_VALUE; if (v > MAX_VALUE) return MAX_VALUE; if (v 可回滚的计算快照（非全量，只存关键断点）
每执行SNAPSHOT_INTERVAL层，将当前depth、partialResult、nodeHash存入轻量数组。
一旦中断（如超时、用户取消），可从最近快照恢复，而不是重头开始。
不复杂但容易忽略：真正的高可靠数学引擎，从来不是“递归越深越厉害”，而是“在哪一层停、为什么停、停了之后怎么续”，全部由你手里的显式栈和状态机说了算。
