应避免使用 eval：它引发代码注入、绕过 CSP 安全策略，并导致引擎无法优化、性能严重下降；JSON.parse、方括号属性访问、策略模式等是安全替代方案。
eval 是 JavaScript 中一个功能强大但极具争议的内置函数：它能将字符串作为代码动态执行。这种能力看似灵活，实则暗藏严重安全漏洞与性能隐患，绝大多数现代开发场景中应明确避免使用。
执行风险：代码注入与权限失控
eval 的最大危险在于它在当前作用域中执行字符串代码，且拥有与调用者完全相同的执行权限。一旦字符串内容来自用户输入、URL 参数、第三方接口或未严格校验的配置，攻击者即可注入任意 JavaScript 代码。
- 例如：
eval('alert(document.cookie)')可直接窃取会话凭证；更隐蔽的构造如eval('fetch("/api/user", {method:"POST", body:JSON.stringify(user)}).then(r=>r.json())')可发起伪造请求 - 即使做了简单关键词过滤（如屏蔽
alert、eval），也极易被绕过（如拼接字符串'al'+'ert'、使用Function构造器、或通过atob解码恶意载荷） - 在 CSP（Content Security Policy）策略下，eval 执行通常被直接禁止，启用它等于主动绕过浏览器安全防线
性能损耗：破坏优化与阻碍引擎工作
V8、SpiderMonkey 等主流 JS 引擎对代码进行多层静态分析与即时编译（JIT）。而 eval 的存在迫使引擎放弃大量优化机会：
- 无法对 eval 调用前后的代码做内联、常量折叠或作用域提升等优化，因为运行时行为不可预测
- 每次调用 eval 都需重新解析、编译字符串内容，无法复用已生成的字节码或 JIT 缓存
- 若 eval 出现在闭包或频繁调用函数中，会导致整个函数被标记为“不可优化”，长期停留在解释执行阶段，显著拖慢执行速度
常见误用场景与安全替代方案
开发者常因便利性误用 eval，其实多数需求都有更健壮的替代方式：
立即学习“Java免费学习笔记（深入）”；
-
解析 JSON 字符串：用
JSON.parse()替代eval('(' + str + ')')—— 它只接受标准 JSON 格式，天然免疫代码注入 -
动态访问对象属性：用方括号语法
obj[propName]或Reflect.get(obj, propName)，而非eval('obj.' + key) - 动态执行逻辑分支：用查表法（对象映射）、switch 或策略模式组织函数，避免拼接并执行代码字符串
-
模板渲染：使用成熟模板引擎（如 Handlebars、Mustache）或现代框架的响应式机制，而非
eval('`' + template + '`')类操作
极少数可接受的边界情况
仅当同时满足以下全部条件时，才可谨慎考虑 eval：
- 字符串内容 100% 来自可信、不可篡改的本地源（如硬编码常量、构建时生成的只读配置）
- 无任何用户可控输入参与字符串拼接或生成过程
- 已确认无可用替代方案（如需动态生成并执行 WebAssembly 模块加载逻辑等底层场景）
- 项目已启用严格 CSP 并禁用 unsafe-eval，此时 eval 实际无法运行，倒逼采用更安全路径
实践中，这些条件几乎无法共存。现代工具链与语言特性（如 Proxy、Reflect、dynamic import()）已覆盖几乎所有曾经依赖 eval 的合理用途。
