17370845950

JavaScript操作JSON仅靠JSON.parse()和JSON.stringify()，其余均为JS对象操作；parse报错主因是字符串格式不合法，如单引号、尾逗号、不可见字符等；stringify会静默忽略undefined/function/symbol，转NaN/Infinity为null，Date转ISO字符串，循环引用直接报错；前后端常见问题在于类型不匹配与错误的Content-Type；深拷贝禁用JSON方案，应优先用structuredClone()。

JavaScript 操作 JSON 数据的核心就两件事：JSON.parse() 把字符串转成对象，JSON.stringify() 把对象转成字符串。其余所有“操作”，都是在 JS 对象层面进行的，不是在 JSON 层面。

为什么 JSON.parse() 会报错？常见原因有哪些

报错几乎都源于字符串格式不合法，而不是 JS 本身的问题。

• JSON.parse() 只接受严格语法：双引号包裹 key 和字符串值，不允许尾逗号，不能有单引号或 undefined / function / NaN
• 后端返回的响应体是空字符串、"null" 字符串、或 404/500 状态但没 throw error，容易被直接 parse
• 浏览器控制台里复制粘贴的 JSON 常含不可见 Unicode 字符（如 \u200b 零宽空格），肉眼不可见但导致解析失败
• 用 fetch().then(r => r.json()) 更安全——它自动检查 Content-Type 并在非 2xx 时 reject，比手动 JSON.parse() 少一层裸 try/catch

JSON.stringify() 的坑：哪些值会消失或被改写

这个函数不是“无损序列化”，很多 JS 值会被静默处理：

• undefined、function、symbol 类型的属性会被完全忽略（连 key 都不出现）
• NaN 和 Infinity 被转为 null
• Date 对象变成 ISO 字符串（"2025-06-15T08:30:00.000Z"），但 new Date().toJSON() 才是真正触发这行为的源头
• 循环引用会直接抛 TypeError: Converting circular structure to JSON，必须用 replacer 函数或第三方库（如 flatted）处理

const obj = { a: 1, b: undefined, c: () => {}, d: new Date() };
console.log(JSON.stringify(obj)); // {"a":1,"d":"2025-06-15T08:30:00.000Z"}

前后端交互中最常出问题的 JSON 场景

不是语法错，而是语义和类型错：

• 后端返回数字 ID 却用了字符串（"123"），前端做 === 判断或数组 findIndex 时失败
• 前端传时间给后端，用 new Date().toString() 或 .toLocaleString()，后端无法解析；应统一用 toISOString() 或时间戳
• 表单数据用 FormData 提交却误设 Content-Type: application/json，导致后端收不到字段（实际该用 multipart/form-data 或先 Object.fromEntries(new FormData(form)) 再 stringify）
• 从 URL 查询参数（location.search）取值后，忘记 decodeURIComponent，再 parse 就可能因中文或特殊字符报错

需要深拷贝时，别直接用 JSON.parse(JSON.stringify(obj))

这是最危险的“快捷方式”——它只适用于纯数据对象（Plain Object），且会丢失：

• 原型链、constructor、getter/setter
• Date、RegExp、Map、Set、TypedArray 等内置对象实例
• undefined、function、symbol、NaN、Infinity
• 循环引用（直接报错）

真要深拷贝，优先用 structuredClone()（现代浏览器支持），或明确业务边界后手写 clone 函数。临时应急也比 JSON 方案多一层类型判断更稳妥。