17370845950

JavaScript JSON转换的核心陷阱是成功解析却语义错误：时间字符串无法还原为Date、null被忽略、循环引用丢失字段、数字精度截断；JSON标准仅支持六种原始类型，自定义类型序列化时被抹平；大整数超Number.MAX_SAFE_INTEGER会失真；解析错误缺乏上下文定位；超大或过深JSON易致OOM；根本问题在于前后端字段语义契约缺失。

JavaScript 中的 JSON 数据转换，最核心的陷阱不是 JSON.parse() 报错，而是它「成功解析却语义错误」——比如时间字符串变 Date 对象失败、null 被忽略、循环引用静默丢失字段，或数字精度被截断。

JSON.parse() 无法自动还原 Date、RegExp、undefined、函数等类型

JSON 标准只支持 null、布尔、数字、字符串、数组、对象六种原始类型。任何自定义结构都会在序列化时被抹平或丢弃。

常见表现：

• new Date().toJSON() 输出字符串，JSON.parse() 后只剩字符串，不再是 Date 实例
• JSON.stringify({ re: /abc/ }) → "{}"（正则被忽略）
• JSON.stringify({ fn: () => {} }) → "{}"
• undefined 在对象中直接被跳过：JSON.stringify({ a: undefined }) → "{}"

解决思路：用 JSON.parse() 的第二个参数 reviver 函数手动识别特定格式字段并重建：

const data = '{"timestamp":"2025-03-15T10:20:30.000Z","count":42}';
const parsed = JSON.parse(data, (key, value) => {
  if (key === 'timestamp' && typeof value === 'string' && /^\d{4}-\d{2}-\d{2}T/.test(value)) {
    return new Date(value);
  }
  return value;
});

数字精度丢失：大整数和小数都可能出问题

JavaScript 使用 IEEE 754 双精度浮点数，能安全表示的最大整数是 Number.MAX_SAFE_INTEGER（9007199254740991）。超过此值的整数在 JSON.parse() 后可能失真。

典型场景：

• ID 字段为 18 位以上数字（如 MongoDB ObjectId、Snowflake ID）
• 后端返回 {"id": 9007199254740992}，JS 解析后变成 9007199254740992 —— 看似一样，但 9007199254740992 === 9007199254740993 会返回 true（已不安全）
• 小数如 0.1 + 0.2 本就存在浮点误差，JSON 不会修复它

对策：

• 对长整型 ID，后端优先返回字符串（"id": "9007199254740992"），前端保持 string 类型处理
• 必要时用 BigInt 手动转换（注意：JSON.parse() 不支持 BigInt 字面量，需额外处理）

JSON.parse() 的错误边界极窄，但错误信息毫无上下文

JSON.parse() 只在语法非法时抛错（如多逗号、单引号、尾部逗号、Unicode 不完整），但错误堆栈不指明第几行第几位。而真实数据常来自接口、localStorage 或用户粘贴，稍有不慎就崩溃。

常见诱因：

• 后端返回 HTML 错误页（如 500 页面）却被当 JSON 解析
• 字符串中混入不可见控制字符（\u2028、\u2029）——合法 JS 字符串，但非法 JSON
• 使用了 JS 允许但 JSON 不允许的尾随逗号：{"a":1,}

防御写法（带位置提示）：

function safeParse(jsonStr) {
  try {
    return JSON.parse(jsonStr);
  } catch (e) {
    if (e instanceof SyntaxError) {
      const { message, column, line } = e;
      console.error(`JSON parse error at ${line}:${column}: ${message}`);
    }
    throw e;
  }
}

嵌套层级过深或超大 JSON 导致栈溢出或内存暴涨

Chrome 默认限制 JSON 解析深度约 10000 层；Node.js v18+ 也有限制。但更现实的问题是：一个 50MB 的 JSON 字符串调用 JSON.parse()，会瞬间分配同等大小的内存对象树，极易 OOM。

适用场景：

• 日志聚合、导出报表、离线缓存等含大量重复结构的数据
• 未做分页的全量列表接口响应

建议做法：

• 服务端按需分页或流式传输（如 NDJSON）
• 前端避免一次性解析整包，改用 stream-json（Node）或 jsonl 解析器（浏览器）逐条处理
• 对 localStorage 存储的 JSON，先用 jsonlint 类工具校验长度与结构复杂度

真正难处理的从来不是「怎么转」，而是「谁负责定义字段语义」——后端说 "status": 0 表示成功，前端却把它当布尔值参与逻辑判断；或者把 "price": "19.99" 当字符串拼接进 DOM，结果价格显示成 "19.99元" 而不是数值计算。JSON 只是载体，契约缺失才是最大陷阱。