允许直接写 JS：方案与语法限制选项

01一句话结论

02背景

现有的 mapping flow 是一个声明式节点图（start / setValue / ifElse / return，10 个比较算子，多节点拼接）。 它的能力上限由算子数量决定，每加一种需求就要加新算子 —— 这实际上是在手搓一门更差的编程语言：没有 lint、没有测试、没有调试器，用户也不愿意学。

03已经实现并实测的部分

这不是纸面方案。沙箱、编辑界面、预览接口已经落地，并且用真实攻击代码实测过。

3.1 沙箱

客户代码运行在 QuickJS（编译为 WebAssembly） 解释器里： 独立的堆，没有 require、process、fetch、定时器， 也没有任何宿主对象能进得去。跨进沙箱的只有 ERP 数据的 JSON 文本， 出来的只有 primitive。

3.2 实测结果（真实攻击代码，非推测）

3.3 工程接入面

04语法限制：三个候选方案

三个方案按"表达力"从窄到宽排列。推荐 方案 B， 但请先看第 5 节 —— 无论选哪个，限制的目的是可支持性与性能可预测性。

// 客户写的全部内容
erp.product.UnitPrice * 100

// 内部包成
(function (erp) { return <客户内容> })

// 允许：多步计算、判空、分支
const price = Number(erp.product.UnitPrice);
if (!Number.isFinite(price)) return undefined;
if (erp.product.status !== 'A') return null;
return Math.round(price * 1.1 * 100) / 100;

// 禁止：循环（性能不可预测的唯一来源）
for (let i = 0; i < 1000000; i++) { ... }   // ← 静态检查拒绝
while (true) { }                            // ← 静态检查拒绝

方案对比

05怎么实现语法限制

限制语法有两条互补的技术路径。二者正交，可以同时使用。

5.1 运行时能力限制（零依赖，可立即用）

QuickJS 提供 ContextOptions.intrinsics，可以在创建沙箱时关闭内置对象。 这部分不需要任何新依赖：

5.2 静态 AST 检查（方案 A / B 需要）

用 JS 解析器把代码解析成 AST，按节点类型白名单放行。这是唯一可靠的做法 —— 用正则表达式做语法检查是错的，会既漏判又误判。

检查时机（两处都要）：

• 保存时 —— 在 UI 上直接拒绝，给出人话错误信息
• 运行时 —— 防御有人绕过 UI 直接改数据库配置

5.3 已有护栏（已实现，与上面正交）

• 100 ms wall-clock 超时（中断处理器，能打断纯计算循环与正则回溯）
• 8 MB 解释器堆 / 128 KB 解释器栈 / 20,000 字符代码长度
• 字段级失败隔离：一行代码失败只影响这一行，不阻塞整批推送
• 每次执行独立 runtime + context，用完即弃

06待决策清单

1. 语法限制选 A / B / C 哪一个？ 推荐 B：满足"不要太严格"，同时用"禁循环"换来性能可预测。
2. 能否引入 acorn 作为运行时依赖？ 方案 A / B 的前提。不加就只剩方案 C 或"接受循环 + 超时兜底"。
3. 循环禁止到什么程度？数组方法（map / filter / reduce）是否也禁？ 它们是循环的化身。若允许，需要限制输入数组规模；若禁止，表达力会明显下降。
4. 正则表达式：完全关闭，还是保留 + 超时兜底？ 关闭能消除一类支持问题；保留能让部分客户迁移更顺。实测超时已能拦住 ReDoS。
5. 代码的版本 / 审计 / 回滚，现在做还是以后做？ 客户在生产环境写代码，改坏了要能回退。这是治理需求，不是安全需求。
6. "谁能写代码"是否需要独立权限门？ 当前复用 ProductMapping 权限。若客户希望"只有管理员能写 JS"，需要新权限位。
7. 预览接口的速率限制 —— 建议独立于语法限制，优先处理。 见第 7 节风险 1，它是当前最实际的风险项。

07已知风险与当前局限

以下都是真实的、尚未处理的项。按建议处理顺序排列。

08验证状态