eval及其变体无法被加固安全，因其执行模型天然拥有当前作用域全部权限，正则白名单不可靠、沙箱存在逃逸风险、CSP策略失效；应改用JSON.parse、表达式解析器或配置驱动映射等可控替代方案。
直接调用 javascript_eval（或类似 eval()、Function()、setTimeout(string) 等动态执行字符串代码的方式）在绝大多数场景下都不安全，且现代框架和 Linter（如 ESLint）默认会报错。它绕过静态分析、破坏 CSP、极易引入 XSS，没有“安全使用”的兜底方案——只有“避免使用”和“用更可控的替代方式”。
为什么 eval() 和它的变体无法被“加固”成安全的？
核心问题不是语法层面能不能加白名单，而是执行模型本身：JavaScript 引擎把字符串当作完整代码上下文执行，拥有当前作用域全部权限（包括访问 document、localStorage、fetch、闭包变量等）。哪怕你过滤了 script 或 fetch 字样，仍可通过 atob()、字符串拼接、原型链调用等方式绕过。
- 正则白名单过滤不可靠，JS 语法灵活度远超正则覆盖能力
- 沙箱如
vm2在 Node.js 中也已被多次爆出逃逸漏洞（如 CVE-2022-36067），浏览器端无真正隔离沙箱 - CSP 的
unsafe-eval会直接让整个策略失效，审计和运维成本陡增
用 JSON.parse() 替代字符串解析计算逻辑
如果原始需求只是“把用户输入的数学表达式或结构化数据转成值”，优先走数据协议而非代码执行。
- 用户提交
"{"price": 199, "tax": 0.12}"→ 直接JSON.parse(input)，不拼接、不执行 - 需要简单计算（如
"1 + 2 * 3"）→ 用现成表达式解析器，如expr-eval（只支持四则/函数，无副作用）或mathjs的evaluate()（可禁用eval模式） - 禁止接受任何含函数调用、点号、方括号、分号的输入；对 JSON 输入始终用
try/catch包裹
const { Parser } = require('expr-eval');
const parser = new Parser();
// 安全：只允许数字、运算符、预定义函数（如 sin, log）
const result = parser.evaluate('2 * (3 + sin(0))'); // → 6
// 危险：下面这行会抛出 SyntaxError，而非执行代码
parser.evaluate('process.exit()');用配置驱动 + 白名单函数映射替代动态调用
如果业务确实需要“根据字符串触发不同行为”（例如低代码平台的事件动作），应将行为抽象为数据，再通过硬编码映射执行。
立即学习“Java免费学习笔记（深入）”；
- 定义动作类型白名单：
["show_alert", "navigate_to", "set_form_value"] - 用户配置传入的是结构化对象：
{ type: "set_form_value", field: "email", value: "{{user.email}}" } - 执行时只查表调用对应函数：
handlers[action.type](action)，不拼接、不反射、不require() - 模板变量插值用
String.replace(/{{([^}]+)}}/g, ...)，而非eval求值
浏览器端特别注意：CSP 和 Function() 的隐蔽风险
Function('return ' + input)() 和 setTimeout(string, 0) 同样触发 CSP 的 unsafe-eval，且比 eval() 更难被开发者识别。它们共享同一套 V8 编译流程，同样能访问闭包和全局对象。
- Webpack/Vite 构建时若启用
eval源码映射（devtool: "eval-source-map"），仅用于开发，上线必须关掉 - Linter 规则要启用
no-implied-eval（捕获setTimeout(string)）、no-eval、no-new-func - Chrome DevTools 控制台里手动敲
eval是调试行为，不能成为线上逻辑依据
真正的边界不在“怎么让 eval 安全”，而在于设计阶段就拒绝把业务逻辑塞进字符串——只要存在一个可被用户控制的字符串最终进了 eval、Function 或 new Function，这个路径就是高危的。替代方案不是技术技巧，是把“执行什么”变成配置，“怎么执行”变成受控函数调用。
