如何识别 JSON 序列化对 Map/Set 的“致死打击” 及恢复方案-js教程-PHP中文网

JSON本身不支持Map和Set，因其仅定义六种原生类型；直接序列化会静默返回{}或[]，需手动转为数组再重建。

如何识别 json 序列化对 map/set 的“致死打击” 及恢复方案

JSON 本身不支持 Map 和 Set，这不是兼容性问题，而是规范限制——它只认六种原生类型：字符串、数字、布尔值、null、对象、数组。Map 和 Set 是 JavaScript 运行时提供的集合类，不属于 JSON 标准。一旦直接传给 JSON.stringify，就会被“静默抹除”：Map 变成 {}，Set 变成 {} 或 []，且反序列化后无法自动还原。这看似安静，实则致命。

一眼识别“已中招”的典型症状

不必运行代码，看这几处就能快速判断是否已被 JSON 序列化“误伤”：

存进 localStorage 后读出来是空对象 {}：比如 localStorage.setItem('cache', JSON.stringify(myMap))，再 JSON.parse(localStorage.getItem('cache')) 得到的不是 Map，而是 {}
控制台打印序列化结果含 {} 或 []，但原始结构明显有键值对或去重元素：例如 new Map([['a', 1], ['b', 2]]) 经 JSON.stringify 后输出 "{}"
跨页面/跨 iframe 传递数据后 Map/Set 内容消失：依赖 postMessage 或 URL 参数拼接时用了 JSON.stringify，接收方拿到的是空结构
服务端返回 JSON，前端尝试用 new Map(res.data) 却报错或为空：因为 res.data 是普通对象或数组，不是可迭代的键值对数组

可靠恢复方案：手动转译 + 显式重建

没有自动修复，只有主动约定。核心逻辑是：序列化前“展开”，反序列化后“重建”。关键不在于多 fancy，而在于两端严格一致。

Json Repair Kit

使用 Node.js 评估修复格式错误的 JSON，自动纠正尾随逗号、单引号、未加引号的键等常见问题，实现文件规范化。

下载

Map 存储时转为二维数组：用 Array.from(map.entries()) 得到 [["k1", v1], ["k2", v2]]，再序列化。读取后用 new Map(array) 恢复
Set 存储时转为普通数组：用 Array.from(set) 或 [...set]，序列化为 [1,2,3]。读取后用 new Set(array) 恢复
加类型标记（适合混合结构）：封装成带 type 字段的对象，如 {"type":"Map","data":[["a",1]]} 或 {"type":"Set","data":[1,2,3]}，反序列化时靠 reviver 函数识别并构造

进阶防护：避免全局污染，用工具函数封装

把转换逻辑收口，比到处写 Array.from 更安全、更易维护。

封装专用存取函数：例如 setMap(key, map) 内部自动转数组并存入；getMap(key) 自动读取并 new Map()，调用方完全无感
在 class 中定义 toJSON：若 Map/Set 是某个类的属性，可在该类上实现 toJSON() 方法，返回可序列化的纯数据结构
换用更强大的序列化库：如 devalue，原生支持 Map/Set/循环引用/undefined 等，输出的是可执行 JS 代码而非纯 JSON，适合 SSR 或复杂状态持久化场景