eval在当前词法作用域中运行，不创建独立作用域；它共享外层环境、动态解析字符串，导致变量污染、优化失效、调试困难及严重安全风险。
eval 不创建独立的作用域，它在**当前执行上下文的词法作用域中运行**，但它的行为常被误认为“动态作用域”——实际是**共享外层词法环境 + 运行时解析字符串代码**，这带来几类关键影响。
变量声明会污染外层作用域
在非严格模式下，eval('var x = 42') 会在调用它的函数作用域中声明变量 x，相当于手动写了一行 var x = 42；严格模式下则抛出语法错误（禁止隐式声明）。
- 函数内
eval('let y = 100')：严格模式下合法，y仅存在于 eval 内部块级作用域（ES2015+ 行为），不会泄漏 - 但
eval('function foo() {}')总是提升到所在函数作用域顶层（即使严格模式） - 重复执行
eval('var z = z || []')可能引发意外覆盖或初始化逻辑错乱
无法访问闭包外的私有绑定
eval 并不突破词法作用域链——它只能访问当前执行上下文中可到达的变量，包括外层函数的 const/let、参数、以及全局对象属性（如 window 或 globalThis）。
- 若在箭头函数中调用
eval，它仍沿用外层函数的this和词法环境，不是“新作用域” - 不能通过
eval读取父作用域中未声明但本应存在的变量（比如拼错名），报ReferenceError，和普通代码一致 - 无法绕过
const冻结或模块的私有导出（例如 eval 不能访问另一个模块内部的#privateField）
调试与静态分析严重受阻
引擎无法在编译期确定 eval 字符串的内容，导致：
- V8 / SpiderMonkey 等跳过对该函数的多数优化（如内联、逃逸分析、JIT 编译缓存）
- Source Map 映射断裂，堆栈追踪中显示
eval at <anonymous></anonymous>，难以定位原始位置 - ESLint、TypeScript、Webpack 等工具无法校验 eval 内部代码的类型、引用或安全风险
- 代码压缩器（如 Terser）通常直接保留 eval 调用，甚至拒绝混淆其参数字符串
安全边界彻底失效
一旦传入不受控字符串，eval 就等于把执行权交给该字符串——它拥有当前上下文全部权限：
- 可读写所有局部变量、调用任意函数、修改原型链、触发网络请求（如果环境允许）
- 即使使用
with或Proxy尝试沙箱化，也无法真正隔离（eval 可反射访问eval.toString或Function.constructor绕过） - Content Security Policy（CSP）中
unsafe-eval会直接禁用所有 eval，且现代框架（React/Vue）默认禁用，提示 “eval is not supported”
真正需要动态执行逻辑时，优先考虑 Function 构造器（作用域更干净）、JSON 解析、模板引擎或 WebAssembly，而不是依赖 eval 的“灵活性”。它不是动态作用域的实现，而是词法作用域的不可控延伸——可控性低、性能差、风险高。
