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，而在于两端严格一致。
-
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 不报错，但输出空对象——静默失败最危险
