报价分成表达式安全求值

为什么要抛弃 eval 处理业务计算

在处理报价、分成等涉及金额的业务逻辑时，开发者常常图省事直接使用 eval() 来执行后端传来的或用户输入的表达式。然而，eval() 会执行任意代码，一旦输入被篡改，轻则业务数据泄露，重则直接导致服务端或前端被 RCE（远程代码执行）攻击。为了解决这一安全隐患，同时又要保持动态计算表达式的灵活性，我们需要一个安全的沙箱环境来替代原生的 eval。

安全数学求值的核心机制

该技能的设计灵感来源于 math-expr 工具箱，其核心在于使用 mathjs 库提供的 evaluate 方法替代危险的 eval。

• 表达式解析与执行：底层依赖 mathjs，它专门用于解析和计算数学表达式。由于 mathjs 只支持数学语法和内置函数，它天然无法执行诸如 process.exit() 或 require('fs') 这类带有副作用的系统级调用。
• 严格的 Scope 隔离：在执行前，必须严格限制传入的 scope（作用域）。技能明确约束不应将业务对象直接注入到表达式环境中，仅允许暴露必要的数学常量或简单的计算上下文，防止对象原型链污染。
• 错误兜底机制：对于非法的表达式或计算异常，技能要求进行完整的异常捕获（try-catch）。这能确保在遇到错误输入时，系统会给出友好的提示信息，而不是让异常直接穿透页面导致前端白屏或崩溃。
• 精度控制：针对金额等敏感数据，建议在返回结果时使用 toFixed() 方法，并根据业务场景设定固定的小数位数（例如金额通常保留 2 位），避免浮点数精度丢失带来的财务对账问题。

适用边界与避坑指南

需要注意的是，该技能的边界仅局限于“纯数学表达式求值”。

• 不要用于复杂逻辑：它不支持条件判断（如 a ? b : c）或循环结构，如果你的需求包含业务分支，请改用结构化代码实现。
• 不要滥用 Scope：切忌将整个业务数据库对象或带有敏感属性的 User 对象传入计算上下文，坚持“最小权限”原则。
• 并非万能的安全沙箱：虽然 mathjs 极大降低了代码注入风险，但面对极其复杂的嵌套表达式时仍可能存在性能瓶颈，建议对表达式长度做合理限制。