JSON.parse()和JSON.stringify()是JavaScript中唯一直接可用的原生JSON处理方法，其他库均基于它们封装；使用时需防范XSS、原型污染、静默丢失及响应体校验缺失等风险。
JSON.parse() 和 JSON.stringify() 是唯一直接可用的原生方法
JavaScript 没有“解析器类”或“生成器对象”，JSON.parse() 和 JSON.stringify() 是标准、安全、且浏览器/Node.js 全平台一致的唯一选择。任何第三方库（如 flatted、superjson）都是对这两个函数的封装或扩展，不能绕过它们的核心逻辑。
常见错误是试图用 eval() 或 Function() 解析 JSON 字符串——这等同于执行任意代码，只要输入含 {"x": "1; alert(1)"} 就会触发 XSS。
JSON.parse() 容易踩的坑：不处理异常、忽略 reviver 参数
JSON.parse() 遇到非法 JSON 会直接抛出 SyntaxError，不加 try/catch 会导致脚本中断。另外，它默认不会校验值类型或过滤敏感字段，比如解析含 __proto__ 或 constructor 的字符串可能干扰原型链。
- 始终包裹在
try/catch中，不要假设输入可控 - 用
reviver函数做基础清洗：过滤掉以_开头的键、拒绝undefined/function类型的值 - 注意
reviver无法阻止原型污染，需额外检查键名是否为"__proto__"或"constructor"
try {
const data = JSON.parse(input, (key, value) => {
if (key === '__proto__' || key === 'constructor') return undefined;
if (typeof value === 'function' || value === undefined) return undefined;
return value;
});
} catch (e) {
console.error('Invalid JSON:', e.message);
}
JSON.stringify() 的隐式丢失：函数、undefined、Symbol、循环引用
JSON.stringify() 不是“深克隆”，它会静默丢弃：function、undefined、Symbol 键或值，以及遇到循环引用时直接报错 TypeError: Converting circular structure to JSON。
立即学习“Java免费学习笔记（深入）”；
- 对象含
method() {}或cb: () => {}→ 该属性彻底消失，无警告 - 键为
Symbol('id')→ 整个键值对被忽略 - 存在
a: { b: {} }; a.b.a = a→ 抛出错误，必须提前检测或用replacer过滤 - 日期对象转成 ISO 字符串，
new Date()→"2024-05-20T12:34:56.789Z"，不是原始 Date 实例
const obj = { x: 1, y: () => {}, z: undefined, [Symbol('k')]: 'v' };
console.log(JSON.stringify(obj)); // {"x":1}
服务端交互时的双重风险：CSP 头缺失 + 响应体未校验
前端用 fetch().then(r => r.json()) 看似安全，但实际分两步：先拿到响应体（可能是 HTML/JS），再调用 JSON.parse()。如果后端返回错误页（如 500 HTML），r.json() 仍会尝试解析，大概率抛出语法错误——但这不是最危险的。
真正风险在于：攻击者若能控制响应体（如通过 SSRF、缓存投毒、中间人），返回一段看似合法 JSON 实际含恶意 JS 的内容，而前端又没校验 Content-Type: application/json，就可能误解析并执行。
- 检查
response.headers.get('content-type')是否包含'application/json' - 避免在
中加载 JSON 数据（绕过 CSP） - 后端务必设置
Content-Security-Policy: default-src 'self'，防止 JSONP 式劫持 - 敏感接口禁用 JSONP，现代应用不应依赖
callback=xxx参数
复杂点在于：JSON 安全不是单点问题，而是输入来源、传输通道、解析上下文、数据用途四者共同决定的。少检查任一环，都可能让看似无害的 JSON.parse() 成为突破口。
