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 函数手动识别特定格式字段并重建：
立即学习“Java免费学习笔记（深入）”；
const data = '{"timestamp":"2024-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 只是载体，契约缺失才是最大陷阱。
