JSON序列化Map/Set致命问题及修复方法

JSON规范天生不支持Map和Set，直接序列化会导致数据静默丢失为{}或[]，看似无错实则致命——localStorage存取后变空、跨页面传值内容消失、服务端响应无法重建集合等都是典型症状；真正可靠的解法不是寻找“自动修复”，而是通过手动转译（Map→二维数组、Set→普通数组）加显式重建，并辅以工具函数封装或专业序列化库（如devalue）来保障一致性与可维护性，同时必须警惕重写全局JSON方法、字符串解析等危险“捷径”。

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，而在于两端严格一致。

• 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 或复杂状态持久化场景

别踩坑：那些看似可行但实际危险的做法

有些“捷径”短期能跑通，长期会埋雷：

• 重写全局 JSON.stringify：容易影响第三方库，且不同环境行为不一致，极难调试
• 用 toString() 或正则匹配还原：比如把 "Set{[1,2,3]}" 当字符串解析，既脆弱又不可靠，遇到嵌套或特殊字符就崩
• 依赖浏览器私有字段（如 map.keys() 结果直接序列化）：不是标准行为，兼容性差，且丢失值部分
• 认为 “只要没报错就是成功”：JSON.stringify 对 Map/Set 不报错，但输出空对象——静默失败最危险

今天关于《JSON序列化Map/Set致命问题及修复方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！