JavaScript中new Function、eval与函数表达式的区别对比

在JavaScript开发中，定义并执行逻辑主要依赖常规函数，但在动态执行字符串代码或构建隔离逻辑时，开发者往往会遇到eval与new Function。表面上看，它们都具备“把字符串当成代码执行”的能力，而函数表达式则是现代应用中最基石的函数声明手段。然而，这三者在词法作用域解析、JavaScript引擎JIT编译优化、安全策略以及运行时内存分配上有着截然不同的底层机制。理解这些差异，是规避隐蔽作用域Bug、编写高执行性能代码和遵循现代安全规范的关键。

一、核心定义与基础语法形式

在深入分析机制之前，先明确三者在语法层面的基本定义方式与典型调用形态：

• 函数表达式（Function Expression）：将函数作为值赋给变量，可以是匿名函数、具名函数或箭头函数。代码在脚本加载与解析阶段完成词法结构的确定。
• eval(string)：内建全局函数，将传入的字符串作为JavaScript表达式或语句直接在当前调用位置同步执行。
• new Function([...args], functionBody)：动态构造函数，参数列表中前面的字符串为形参名，最后一个字符串为函数体，运行时动态编译并返回一个全新的函数实例。

// 1. 函数表达式
const addExpr = function(a, b) {
  return a + b;
};

// 2. eval 动态执行
const a = 10, b = 20;
const evalResult = eval("a + b");

// 3. new Function 构造函数
const addDynamic = new Function("a", "b", "return a + b;");
const funcResult = addDynamic(10, 20);

图1：函数表达式、eval与new Function的作用域查找路径与绑定机制对比

二、作用域绑定与闭包捕获差异

三者在实际执行中最关键的差异体现在作用域解析规则上。无论嵌套在多深的代码块中，它们的表现完全不同：

1. eval：直接穿透当前调用上下文

直接调用 eval() 会保留调用点的完整词法环境。它不仅能读取当前函数的局部变量，在非严格模式下，还能通过声明语句向当前函数注入新的变量，甚至覆写外部变量：

function testEval() {
  let secret = "local_token";
  eval("secret = 'modified_by_eval'; var injected = 999;");
  console.log(secret);   // 输出: "modified_by_eval"
  console.log(injected); // 非严格模式下输出: 999
}
testEval();

2. new Function：强制将全局作为父级环境

与 eval 截然相反，new Function 生成的函数永远在全局作用域中创建。即使在嵌套多层的函数或块级作用域中执行 new Function，它也无法闭包捕获当前函数内的局部变量，只能访问全局对象上的属性：

let globalVal = "global";

function testFunctionConstructor() {
  let localVal = "local";
  
  // 试图在函数体内访问 localVal
  const fn = new Function("return typeof localVal !== 'undefined' ? localVal : 'undefined';");
  console.log(fn()); // 输出: "undefined"（无法读取局部变量）

  const fnGlobal = new Function("return globalVal;");
  console.log(fnGlobal()); // 输出: "global"
}
testFunctionConstructor();

这种机制使得 new Function 天然具备了一定程度的局部隔离性——它不会因为意外读取或篡改调用方的局部私有数据而引发隐蔽副作用。

3. 函数表达式：标准的词法作用域闭包

函数表达式完全遵循 JavaScript 的静态词法作用域规则。在声明函数表达式的位置，它静态地绑定了当前环境中的变量引用，形成闭包，不受调用时机或外部执行位置的影响，生命周期与状态安全可控。

三、解析时机与 JIT 引擎优化流程

现代 JavaScript 引擎（如 Google Chrome/Node.js 使用的 V8）使用分层编译管线：首先通过 Parser 将源码解析为抽象语法树（AST），由 Ignition 生成字节码，随后在热点代码执行时由 TurboFan 进行高度激进的 JIT（即时编译）优化。这三种声明方式对编译器的优化管线有根本性的影响。

图2：代码解析执行路径与V8引擎JIT去优化机制推导

在性能层面，主要产生三个维度的差异：

1. 编译器提前优化能力（Ahead-of-Time Optimization）：函数表达式在初始解析脚本时即完成了词法分析与变量槽位（Slot）分配，引擎能确定变量不会被意外覆写，从而将其放入 CPU 寄存器中加速。
2. 运行时解析成本（Parsing Overhead）：eval 和 new Function 都要求浏览器在运行时临时唤醒 JavaScript 解析器和词法分析器。如果在高频循环或动画帧中反复执行，会产生显著的 CPU 耗时与垃圾回收（GC）压力。
3. 去优化连带效应（Deoptimization Cascade）：直接使用 eval 会“毒化”它所在的整个函数。由于引擎无法在编译期预测 eval 内部会改变哪些变量，编译器只能放弃对宿主函数的一切激进假设（例如内联优化与类型特化），被迫回退到慢速查表访问模式。

四、安全隐患与内容安全策略 (CSP) 限制

除了性能和作用域，在企业级生产系统中最不可忽视的是安全性限制。动态执行字符串构成了跨站脚本攻击（XSS）和任意代码执行（RCE）的高发入口。

图3：处理动态逻辑时的安全考量与CSP内容安全策略决策路径

关于内容安全策略（Content Security Policy, CSP）的约束规范：

• 现代 Web 应用普遍配置了强安全级别的 HTTP 响应头 Content-Security-Policy: default-src 'self'。在此策略下，浏览器会直接禁用一切形式的字符串转可执行代码功能。
• 无论是 eval("...") 还是 new Function("...")，只要执行都会立即抛出 EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive...。
• 函数表达式属于在独立脚本或静态资源中加载的正常代码，不会触发任何 CSP 违规警告。

五、实际场景代码行为差异对照

1. 变量读写与局部遮蔽验证

let score = 50;

function evaluateLocal() {
  let score = 90;

  // 1. 函数表达式：能够直接利用闭包读取当前函数的 score (90)
  const fnExpr = () => score;

  // 2. eval：直接读取调用现场的 score (90)
  const evalScore = eval("score");

  // 3. new Function：无视调用现场，读取全局 score (50)
  const fnNew = new Function("return score;");

  console.log("函数表达式结果:", fnExpr());     // 90
  console.log("eval 执行结果:", evalScore);     // 90
  console.log("new Function 执行结果:", fnNew()); // 50
}

evaluateLocal();

2. 循环重复调用的性能对比

// 场景：对数组进行复杂运算求和
const list = Array.from({ length: 10000 }, (_, i) => i);

// 方式A: 函数表达式 (提前编译优化)
const addOp = (x) => x * 2 + 1;
console.time("函数表达式");
let sumA = 0;
for (let i = 0; i < list.length; i++) {
  sumA += addOp(list[i]);
}
console.timeEnd("函数表达式"); // 通常 < 1ms

// 方式B: 循环内反复 new Function (反复唤起解析器)
console.time("反复 new Function");
let sumB = 0;
for (let i = 0; i < list.length; i++) {
  const dynamicFn = new Function("x", "return x * 2 + 1;");
  sumB += dynamicFn(list[i]);
}
console.timeEnd("反复 new Function"); // 显著慢数十倍甚至数百倍

// 方式C: 循环内反复 eval
console.time("反复 eval");
let sumC = 0;
for (let i = 0; i < list.length; i++) {
  sumC += eval("list[i] * 2 + 1");
}
console.timeEnd("反复 eval"); // 极度缓慢，引擎无法内联优化

图4：JavaScript函数表达式、new Function与eval的综合特性对比矩阵

六、总结与技术选型建议

通过对作用域、执行性能与安全策略的全面对比，可以得出明确的技术选型建议：

• 常规业务开发，无条件选择函数表达式：无论是高阶函数传递、组件事件绑定还是纯工具函数编写，函数表达式（包括箭头函数）均享有现代引擎最完善的 JIT 优化支持和编译期静态检查。
• 需要动态构造逻辑时，优先考虑解析替代方案：如果业务目标是解析用户输入的数学表达式或模板变量，优先使用基于有限状态机（FSM）或语法树（AST）的小型解析库（如 Math.js），而不是直接将原始字符串丢给解释器。
• 若必须在运行时编译字符串逻辑，使用 new Function 替代 eval：如果开发轻量级前端模板引擎（如类似 lodash.template 的实现），new Function 可以通过显式传递形参（如 new Function("data", templateBody)）来清晰界定输入边界，且完全不会污染局部上下文或破坏调用方的 JIT 优化状态。
• 彻底在现代工程中禁用 eval：在 ESLint 中配置 no-eval 规则将其拦截在提交阶段。eval 带来的微弱灵活性远不能弥补其在安全性、调试难度与执行性能上的巨大代价。