eval 会严重降低 JavaScript 性能：破坏编译优化路径，强制每次执行都重新解析编译；阻断 JIT 深度优化，使函数长期处于解释执行；并加重垃圾回收压力，内存占用可达普通代码的 3–5 倍。
eval 会直接破坏 JavaScript 引擎的编译优化路径，导致运行时性能显著下降。
引擎无法做静态作用域分析
JavaScript 引擎（如 V8）在编译阶段会预先确定变量声明位置、作用域层级和标识符绑定关系，从而生成高效查找路径（比如内联缓存、栈帧预分配）。但 eval 的参数是运行时才确定的字符串，引擎无法提前知道它是否会声明新变量、修改已有变量，或引入嵌套作用域。于是引擎只能放弃所有相关优化，退回到最保守的动态查找模式。
每次调用都触发完整解析-编译流程
正常函数代码只在首次加载或首次调用时经历一次词法分析、语法解析和字节码生成。而 eval 每次执行，都会强制引擎重新走一遍完整流程：
- 将字符串切分为 token（词法分析）
- 构建抽象语法树（语法分析）
- 生成可执行字节码或机器码（编译）
- 再立即执行
这个过程没有缓存机制，也无法复用已有的优化上下文，开销远高于普通函数调用。
立即学习“Java免费学习笔记（深入）”；
阻断 JIT 编译器的深度优化
V8 的 TurboFan 等 JIT 编译器依赖稳定的作用域结构进行类型推断、函数内联、逃逸分析等高级优化。一旦函数体内存在 eval，TurboFan 会直接标记该函数为“不可优化”，长期停留在解释执行（Ignition）阶段。即使只在某个分支里调用 eval，整个函数都可能失去优化资格。
间接影响内存与 GC 行为
eval 动态创建的变量、函数或闭包，其生命周期难以被引擎准确追踪。尤其在频繁调用 eval 的场景中，容易产生短生命周期但结构复杂的临时作用域环境，加重垃圾回收压力。实测显示，在循环中每轮调用 eval("x++")，内存占用增长速度可达同等逻辑普通代码的 3–5 倍。
