eval 的核心问题是模糊数据与代码边界，导致执行权失控；其作用域共享、无法隔离、变量污染及调试困难等缺陷使其极度危险，应按场景采用 JSON.parse、表达式解析器或白名单映射等安全替代方案。
eval 的核心问题不是“能不能算”，而是“谁来决定这段字符串是不是代码”。它把数据和代码的边界彻底抹掉，一旦输入不可控，就等于把执行权交给了攻击者。
作用域失控：eval 没有真正的“沙箱”
eval 执行时默认共享当前函数的所有变量、闭包状态和 this 绑定。它不是在新环境里跑，而是在你代码最敏感的地方直接插了一段外部指令。
- 无法隔离：哪怕只写
eval("x + 1")，x 可能来自用户输入、API 响应或配置文件，而 eval 会无条件访问它 - 污染风险：eval 内部声明的 var 变量会泄漏到外层作用域（ES5 行为），可能覆盖关键变量
- 调试困难：堆栈追踪中看不到 eval 内部的真实调用路径，错误定位成本高
安全替代方案按场景分类
真正安全的替代，不是找一个“差不多的函数”，而是根据实际需求切换思维模式：从“执行代码”转向“解析数据”或“查表映射”。
-
只是想转 JSON？ 强制后端返回标准 JSON，前端统一用
JSON.parse()。若遇非标格式（如 key 无引号），先用正则或专用清洗工具规整，再 parse —— 不走 eval，不拼括号 -
只想算个表达式？ 用
expr-eval（JS）或ast.literal_eval（Python）。它们只认数字、布尔、列表、字典等字面量，拒绝函数调用、属性访问、副作用语句 -
要根据字符串触发行为？ 定义白名单动作对象：
{ type: "save", data: {...} }，执行层硬编码 handler 映射：handlers[action.type]?.(action)，杜绝字符串拼接函数名 -
必须动态生成函数？ 在可信环境下优先用
new Function('a', 'b', 'return a + b')，它默认在全局作用域执行，不捕获闭包，比 eval 更可控
永远不该绕过的底线
任何把用户输入、网络响应、本地存储内容直接喂给 eval 或类似机制（如 Python 的 exec、PHP 的 assert）的行为，都等同于主动放弃输入校验。
- 不依赖“看起来安全”的正则过滤，因为语法解析器比正则强大得多
- 不信任“只允许数字和运算符”的白名单，攻击者总能找到绕过方式（如 Unicode 零宽字符、编码混淆）
- 不把安全寄托在运行时 try/catch 上——异常拦不住 XSS、RCE 或数据窃取
不复杂但容易忽略：安全不是加一层防护，而是从设计源头拒绝把字符串当代码执行。
