为什么JavaScript解析JSON推荐用JSON.parse而非eval

在 JavaScript 中将 JSON 格式的字符串还原为对象时，现代前端与后端开发规范无一例外地明确要求使用 JSON.parse()，并明令禁止使用 eval()。两者的根本区别在于：JSON.parse() 是专门用于反序列化纯数据的静态解析器，只接受严格遵循 JSON 规范的格式，不会执行任何可执行代码；而 eval() 是底层的完整 JavaScript 编译器与运行时执行器，会毫无保留地把传入字符串当作普通 JavaScript 代码编译并赋予其运行权限。

一、核心机制差异：纯数据解析 vs 完整脚本执行

要理解两者的优劣，首先需要从底层的执行流程看起。JSON.parse() 在底层被设计为一个纯状态机驱动的词法语法解析器，它只关心数据结构，从根本上隔离了代码执行环境。当字符串传入 JSON.parse() 时，引擎只进行简单的标点符号、键值对及基本数据类型的校验与还原。

相对而言，eval() 接收到字符串后，会启动完整的 JavaScript 解析器、编译器与代码生成流程。引擎必须为这段字符串建立词法作用域链，检查是否包含变量声明、函数调用、对象属性修改甚至作用域拦截操作。

图 1：JSON.parse 与 eval 在底层处理流程上的本质区别

二、致命隐患：eval 带来的代码注入与安全漏洞

安全性是弃用 eval() 解析 JSON 最直接也是最不可忽视的理由。在真实业务场景中，JSON 字符串通常来自接口网络请求、用户输入或第三方公开 API。如果直接使用 eval() 接收不可信源的数据，恶意攻击者只需在数据包中嵌入合法的 JavaScript 表达式，就能在用户浏览器或 Node.js 服务端环境中静默执行任意脚本。

// 模拟不可信的外部输入字符串
const untrustedData = '{"username": "guest", "alert": alert(document.cookie)}';

// 危险操作：eval 会立即执行 alert 并窃取敏感信息
// 为了让 eval 将花括号解析为表达式对象，历史上常被写为 eval("(" + str + ")")
const badUser = eval("(" + untrustedData + ")"); 

// 安全操作：JSON.parse 识别到函数调用等非法格式，直接抛出异常拦截威胁
try {
  const safeUser = JSON.parse(untrustedData);
} catch (err) {
  console.error("成功拦截非标准 JSON 及潜在攻击脚本:", err.message);
  // 输出：Unexpected token 'a', "{"username"... is not valid JSON
}

图 2：恶意 Payload 在不同解析方式下的行为对比

三、性能鸿沟：专用快速路径 vs 破坏 JIT 优化

很多初学者会误以为 eval() 是语言底层方法，执行速度不会比 JSON.parse() 慢。然而在现代 JavaScript 引擎（如 Google V8、JavaScriptCore 或 SpiderMonkey）中，两者的性能差距通常在数倍到数十倍之间：

• 专用 C++ 高速解析器：JSON.parse() 是由引擎内建的专门 C++ 模块实现的，直接以单遍扫描算法输出内存对象模型，无需经历昂贵的抽象语法树（AST）构建与字节码生成阶段。
• 破坏 JIT 编译优化：eval() 具有动态改变本地作用域的能力。为了防范 eval() 隐式修改局部变量，当函数内部出现 eval() 时，JavaScript 引擎的 JIT 编译器会被迫禁用内联缓存、隐藏类推导以及变量逃逸分析等激进优化策略，导致整个作用域的执行性能整体降级。

四、语法与规范：严格数据契约 vs 隐蔽的格式宽容

JSON 是一种跨语言的数据交换格式，其标准（RFC 8259）定义了极度严格的语法规则。而 JavaScript 对象字面量（Object Literal）规范比 JSON 宽松得多。使用 eval() 解析时，会带来隐蔽的兼容性陷阱。

图 3：数据规范性校验与边界处理逻辑

常见格式差异包括：

1. 键名必须双引号：JSON 强制键名包裹在 ASCII 双引号（"key"）中。单引号或无引号对象在 JavaScript 字面量中合法，但在 JSON 中会导致语法错误。eval() 会放行无引号键名，导致开发者未能及时发现前端发送的格式不合规，引发跨语言后端微服务解析崩溃。
2. 尾逗号（Trailing Comma）：JSON 不允许在最后一个元素后面添加多余的逗号，而现代 JavaScript 语法允许。JSON.parse() 能严格把关这一边界。
3. 特殊值限制：JSON 中不支持 undefined、NaN、Infinity 及原生函数。eval() 在解析时会隐式接受这些特殊值，造成后续业务逻辑中 typeof 校验出现意料之外的错误。

五、实操对比：语法书写陷阱与 reviver 高级用法

即使在不考虑安全性的极度受控场景下，使用 eval() 解析对象也有一个极其别扭的语法陷阱：在 JavaScript 语法中，顶层花括号 {} 默认会被优先识别为“语句块（Block）”而非“对象字面量（Object Literal）”。

const jsonStr = '{"status": 200}';

// 语法错误：引擎认为这是带标签的空代码块
// Uncaught SyntaxError: Unexpected token ':'
// eval(jsonStr); 

// 必须手动包裹圆括号强制转为表达式求值：
const objFromEval = eval("(" + jsonStr + ")");
console.log(objFromEval.status); // 200

// 而 JSON.parse 语义明确且安全：
const objFromParse = JSON.parse(jsonStr);
console.log(objFromParse.status); // 200

// 使用 reviver 将日期字符串还原为真实的 Date 对象
const payload = '{"title":"Report","createdAt":"2026-10-25T10:00:00.000Z"}';

const record = JSON.parse(payload, (key, value) => {
  if (key === "createdAt") {
    return new Date(value); // 自动实例化
  }
  return value;
});

console.log(record.createdAt instanceof Date); // true
console.log(record.createdAt.getFullYear());   // 2026

六、技术选型与综合决策总结

为了直观对比两者的多维特性，下表总结了在生产实践中必须坚决使用 JSON.parse() 的核心维度：

图 4：现代 JavaScript 解析场景决策矩阵

综上所述，推荐使用 JSON.parse() 而非 eval() 是现代 Web 工程化演进的必然结果。前者构筑了坚固的安全沙箱，提供了卓越的原生处理速度，并严格维护了跨语言通用的数据交换契约；而后者则是为动态代码求值设计的低阶接口，绝不应当用于日常的数据反序列化场景。