各位好，欢迎来到“状态序列化地狱”的现场。
我是你们今天的讲师。我知道，听到“序列化”这三个字，大家的眼神已经涣散了。这听起来像是那种会让实习生在周五下午崩溃的枯燥任务。但是，各位，序列化是 React 世界的“血管系统”。没有它，你的应用就是一堆散落在内存里的无头尸体，无法跨越浏览器、服务器，甚至是桌面窗口的边界。
今天我们不谈什么“Hello World”，我们来谈谈那些让你头皮发麻的坑：数据类型损耗。
想象一下，你的 React 组件里有一个五彩斑斓的按钮，它的 onClick 事件里藏着一段复杂的业务逻辑。你把它传给了 Electron 的主进程，或者你在 Next.js 的服务端渲染（SSR）里把它存进了 window.__INITIAL_STATE__。然后，当你试图在另一个进程或者另一个时间点把它读回来时，发现那个按钮变成了一块死木头——它原本的“灵魂”（函数）消失了，原本的“性格”（Symbol）不见了，甚至连原本的“长相”（引用关系）都变了。
这就叫“数据类型损耗”。
我们今天要做的，就是如何用手术刀般的精准，缝合这些被 JSON 格式无情吞噬的伤口。
第一章：JSON 是个无情的杀手
首先，我们要面对这个残酷的现实：JSON 是数据的尸体。
当你调用 JSON.stringify() 时，你实际上是在对对象进行“安乐死”。你把活生生的 JS 对象变成了僵硬的文本字符串。
看看这个例子：
const userState = {
id: 1,
isAdmin: true,
name: "React Master",
greet: () => {
console.log("Hello, World!");
},
[Symbol("secret")]: "This is a symbol",
// 一个循环引用，典型的家庭矛盾
friend: null
};
userState.friend = userState;
console.log(JSON.stringify(userState, null, 2));输出结果：
{
"id": 1,
"isAdmin": true,
"name": "React Master",
"friend": "[Circular]"
}发生了什么？
- 函数去哪了？
greet函数消失了。因为在 JSON 的世界里，没有“行为”，只有“数据”。函数是代码，不是数据。这就像你把一个会唱歌的人关进盒子里，打开盒子，里面只有一张写着“我会唱歌”的纸条。 - Symbol 去哪了？
Symbol("secret")消失了。Symbol 是 JavaScript 里最神秘的幽灵，它不参与默认的序列化。如果你在服务端生成了一个 Symbol，在客户端想用它做 Key，那你只能撞墙。 - 循环引用去哪了？
friend变成了字符串"[Circular]"。这意味着引用关系断裂了。你的状态树变成了一个孤岛。
这就是为什么 SSR（服务端渲染）时，如果你的状态里包含组件实例（比如 ref.current），Hydration（水合）阶段就会直接炸裂。
第二章：桌面端通信的“幽灵事件”
让我们把场景切换到桌面端开发。假设你在写一个基于 Tauri 或 Electron 的 React 应用。
在桌面应用里，主进程和渲染进程是隔离的沙盒。数据不能像在浏览器里那样直接共享。你必须通过 IPC（进程间通信）传递消息。
错误的姿势：
// 渲染进程
const handleSync = () => {
// 假设这是你的组件状态
const complexState = {
items: [1, 2, 3],
callbacks: {
onSave: (data) => {
console.log("Saving:", data);
},
onLoad: () => {
alert("Data Loaded!");
}
}
};
// 发送给主进程
window.electronAPI.sendState(complexState);
};当你发送这个数据后，主进程收到了什么？
// 主进程
ipcMain.handle('send-state', (event, state) => {
console.log(state);
});主进程日志：
{
items: [1, 2, 3],
callbacks: {} // 空的！
}你的回调函数全丢了！主进程拿到这个数据后，根本不知道该执行什么逻辑。你试图在主进程里重新定义这些函数，但这会导致代码重复，甚至逻辑不一致。
这就是典型的“类型损耗”。 这种损耗不仅仅是数据少了，它是逻辑的缺失。
第三章：Map 和 Set —— 被遗忘的救世主
既然普通对象（POJO）和数组在序列化时如此脆弱，我们该怎么办？
我们需要寻找那些天生支持序列化的数据结构。
答案就是：Map 和 Set。
是的，你没听错。虽然它们看起来和 Object、Array 一样，但它们是“干净”的。
// 使用 Map
const mapState = new Map([
["userId", 101],
["username", "DevOpsGod"],
["settings", { theme: "dark" }]
]);
// 使用 Set
const setState = new Set([1, 2, 3, 3, 4]); // 自动去重
console.log(JSON.stringify(mapState)); // {"userId":101,"username":"DevOpsGod","settings":{"theme":"dark"}}
console.log(JSON.stringify(setState)); // [1,2,3,4]为什么 Map 好用？
因为 Map 的 Key 必须是字符串或者 Symbol。这完美符合 JSON 的规范。而且，Map 是有序的。当你序列化一个 Map 时，它的顺序是确定的。而普通对象在序列化时，Key 的顺序是不确定的（取决于 V8 引擎的垃圾回收策略，虽然最近有改进，但依然不可靠）。在跨端同步中，顺序一致性至关重要。
实战技巧：
如果你需要在 React 状态里存储一些临时数据，或者需要去重的数据，强烈建议使用 useMap 或 useSet 这样的自定义 Hook，而不是普通的数组。
// 一个简单的 useMap Hook
function useMap(initial = new Map()) {
const [map, setMap] = useState(initial);
return [
map,
{
set: (key, value) => setMap(new Map(map).set(key, value)),
delete: (key) => setMap(new Map(map).delete(key)),
get: (key) => map.get(key),
// ... 其他方法
}
];
}使用 useMap，你的状态就可以被安全地序列化。这就像是给你的数据穿上了一层防弹衣。
第四章：自定义序列化器 —— 编写你的“屠龙宝刀”
但是，Map/Set 并不能解决所有问题。有时候，你必须使用对象，或者你需要处理 Date、RegExp、Error，甚至是循环引用。
这时候，你需要一个自定义序列化器。这听起来很高大上，其实就是写几个递归函数。
1. 处理 Date 和 RegExp
JSON 不认识 new Date()，它会把 Date 变成时间戳字符串 1700000000000，或者 null。如果你需要保留时区信息，必须手动转换。
const serializeDate = (value) => {
if (value instanceof Date) {
return {
__type: "Date",
value: value.toISOString()
};
}
return value;
};
const deserializeDate = (value) => {
if (value && value.__type === "Date") {
return new Date(value.value);
}
return value;
};2. 处理循环引用 —— 处理“家庭矛盾”
循环引用是序列化的头号公敌。怎么处理？我们用一个“身份证”系统。
const seen = new WeakMap();
function safeStringify(obj, indent = 2) {
const cache = new Set();
return JSON.stringify(obj, (key, value) => {
// 1. 检查是否是循环引用
if (typeof value === "object" && value !== null) {
if (cache.has(value)) {
// 遇到循环引用，返回一个特殊的标记
return "[Circular]";
}
cache.add(value);
}
return value;
}, indent);
}注意： WeakMap 或 Set 在 JSON 序列化时会被自动过滤掉。所以上面的代码中，cache 不会出现在最终的 JSON 字符串里。它只是在序列化过程中作为一个“安检员”存在。
3. 处理 BigInt —— 精度的噩梦
在金融或科学计算中，BigInt 是必不可少的。但是，JSON 不支持 BigInt。JSON.stringify(BigInt(123)) 会直接报错。
// 处理 BigInt
const replacer = (key, value) => {
if (typeof value === "bigint") {
return value.toString(); // 或者 return { __type: "BigInt", value: value.toString() };
}
return value;
};
try {
console.log(JSON.stringify({ bigNumber: BigInt("9007199254740991") }, replacer));
} catch (e) {
console.error("Boom!");
}使用 replacer 函数，你可以拦截序列化过程，把 BigInt 转成字符串，反序列化时再转回去。
第五章：不可变数据 —— 架构师的信仰
如果你在 React 里到处都是 state.items.push()，那么你的序列化噩梦才刚刚开始。
为什么？因为可变数据会导致引用混乱。JSON.stringify 是基于引用的。如果两个不同的变量引用了同一个对象，序列化出来的结果里，这个对象只会出现一次。
但这在 React 状态管理中是个大问题。因为 React 需要依赖引用变化来触发重渲染。如果你修改了一个嵌套对象，而它的父级引用没变，React 就会认为“这事儿跟我没关系”，于是它就不渲染。
所以，为了序列化，也为了 React 的性能，请拥抱不可变数据。
使用 Immer 吧。它能让写不可变代码像写可变代码一样爽。
import produce from 'immer';
const nextState = produce(currentState, draft => {
draft.items.push({ id: 4, name: "New Item" }); // 直接改，Immer 会帮你生成新引用
});当你使用 Immer 修改状态后，你的状态树结构会非常清晰，所有的节点都是新的对象。这对于序列化器来说，简直是天使的礼物。它不需要担心“哪个属性引用了旧的节点”，因为它全是新的节点。
第六章：跨端同步的终极形态 —— 结构化克隆算法
如果你现在使用的是现代浏览器（Chrome 83+, Firefox 94+, Safari 15.4+），你其实有一个内置的“黑科技”：结构化克隆算法。
它不是 JSON.stringify，但它的功能比 JSON.stringify 强大得多。它支持：
- 循环引用：它能处理循环引用！
- Blob, File, ArrayBuffer：它能序列化二进制数据。
- DOM 节点：它能序列化 DOM 节点（虽然这通常是个馊主意，但在某些 Web Worker 场景下有用）。
- 丢失的数据：它不会丢失函数（虽然通常也没必要保留函数）。
怎么用？
const obj = {
a: 1,
b: { c: 2 },
d: () => console.log("Hi")
};
// 结构化克隆
const clonedObj = structuredClone(obj);
console.log(clonedObj);
// { a: 1, b: { c: 2 } }
// 函数 d 没了，但至少没有报错崩溃！但是！ 它依然不支持 Map, Set, Date（除非你手动转换）。而且，它依然不支持 Symbol。
所以，structuredClone 是一个很好的“第一道防线”，它能防止你的应用因为循环引用而崩溃，但如果你需要保留 Map 或者自定义的复杂对象，你依然需要自己动手写序列化逻辑。
第七章：桌面端通信实战 —— MessagePack 的诱惑
回到桌面端通信。Electron 和 Tauri 之间的 IPC 通信，默认也是基于 JSON 的。
虽然 JSON 很通用，但它有个致命弱点：体积大。
如果你传输一个包含大量数据的复杂状态树，JSON 字符串会非常长，占用带宽，解析也需要时间。
这时候，一位老朋友登场了：MessagePack。
MessagePack 是一个高效的二进制序列化格式。它比 JSON 更小、更快。
Electron 中的 MessagePack 示例：
首先安装：npm install msgpackr
// 渲染进程
import msgpackr from 'msgpackr';
const state = {
user: { id: 1, name: "Alice", preferences: { theme: "dark", notifications: true } },
items: Array.from({ length: 1000 }, (_, i) => ({ id: i, val: i * Math.random() }))
};
// 序列化
const buffer = msgpackr.pack(state);
// 发送给主进程
window.electronAPI.sendState(buffer);
// 主进程
ipcMain.handle('send-state', (event, buffer) => {
// 反序列化
const state = msgpackr.unpack(buffer);
console.log(state.user.name); // "Alice"
});优势：
- 体积小：二进制数据通常比文本小 30%-50%。
- 速度快：解析速度通常比 JSON 快 2-3 倍。
- 支持更多类型：MessagePack 原生支持 Map、Array、Int8、Int16 等各种整数类型，不像 JSON 只能用 Number（会丢失精度）。
虽然 MessagePack 的学习曲线稍微陡峭一点（需要引入新的库），但在高频率、大数据量的跨端通信中，它是性价比最高的选择。
第八章：Redux Toolkit 的默认序列化器
如果你在使用 Redux Toolkit，恭喜你，你踩中了一个巨大的坑。
Redux Toolkit 默认使用 createJSONStorage，它使用的是 localStorage。而 localStorage 只支持字符串。
当你调用 store.subscribe 或者 store.dispatch 时，Redux 会尝试把你的整个 State 序列化成字符串存进去。如果你的 State 里有一个 Date 对象，或者一个 Map，它就会直接报错：Converting circular structure to JSON。
解决方案：
你需要自定义一个序列化器。
import { configureStore } from '@reduxjs/toolkit';
import { createJSONStorage, persist } from 'redux-persist';
// 自定义序列化器
const customSerialize = {
deserialize: (value) => {
// 这里通常用 JSON.parse，因为 Redux 里的数据结构相对简单
// 但如果涉及到特殊对象，可以在这里做处理
return JSON.parse(value);
},
serialize: (value) => {
// 把 Map/Set 转成普通对象
const plainObject = {};
for (const [key, val] of value.entries()) {
plainObject[key] = val;
}
return JSON.stringify(plainObject);
}
};
const store = configureStore({
reducer: { ... },
middleware: (getDefaultMiddleware) =>
getDefaultMiddleware({
serializableCheck: {
ignoredActions: ['persist/PERSIST', 'persist/REHYDRATE'],
// 你可以忽略某些 action，或者使用自定义的 check
},
}),
// 如果使用 redux-persist
// persist({
// key: 'root',
// storage: createJSONStorage(() => localStorage, customSerialize),
// })
});注意，Redux Toolkit 的 serializableCheck 默认会拦截那些包含非序列化值的 Action（比如 Date, Function, Map）。这虽然能防止错误，但也可能导致某些合法的 Action 被忽略。你需要学会配置它，而不是一刀切地关闭它。
第九章：Web Worker 中的状态同步
Web Worker 是另一个典型的跨端（跨线程）场景。
主线程和 Worker 线程是完全隔离的。你不能直接把主线程的 state 传给 Worker。
传统做法：
- 主线程：
JSON.stringify(state)-> 发送字符串 -> Worker。 - Worker：
JSON.parse(str)-> 更新 Worker 内部状态。
问题：
这种“发球-接球”的模式非常低效。每次主线程更新数据，都要把整个巨大的状态树序列化并发送给 Worker。如果状态树有 10MB，每次点击按钮都要发 10MB 的数据包，网络会卡死，CPU 会爆表。
优化方案：
使用 postMessage 的 Transferable Objects（可转移对象）。
如果你有一个 ArrayBuffer（比如图片数据、视频帧数据），你可以把它“转移”给 Worker，而不是“拷贝”给它。
// 主线程
const buffer = new ArrayBuffer(1024 * 1024); // 1MB
// ... 填充 buffer ...
// 发送给 Worker，transferList 指定 buffer 所有权转移
worker.postMessage({ type: 'FRAME', buffer }, [buffer]);
// 此时主线程的 buffer 已经是 null 了！但对于普通的 JS 对象，我们依然依赖 JSON。但我们可以使用 structuredClone 来优化性能，因为它比 JSON.stringify + JSON.parse 快得多。
第十章：不要把“秘密”带进序列化器
最后，我想讲一个哲学问题。
序列化器是一个过滤器。它会把你对象里的“杂质”过滤掉。
如果你在状态里存了：
- 组件实例：
<MyComponent />-> 序列化后：null。 - DOM 节点：
document.getElementById('app')-> 序列化后：null。 - 闭包变量：函数内部的局部变量 -> 序列化后：
undefined。 - 私有属性：以
_开头的属性 -> 序列化后：undefined。
这是设计缺陷，不是 Bug。
React 的状态应该是纯数据。它应该只包含你想要跨端同步的数据。
如果你在状态里存了组件实例，说明你的架构设计有问题。组件实例是 UI 的表现，不是数据。数据应该驱动 UI，而不是 UI 被塞进数据里。
所以，在写代码之前，先问自己一个问题：
“如果我现在把整个 Redux store 或 Context 发送给一个不认识 React 的后端程序，它还能读懂这些数据吗？”
如果答案是否定的，那就重构你的状态结构。
结语：拥抱数据，而不是对抗它
好了，各位。我们聊了 JSON.stringify 的残酷，聊了 Map 和 Set 的救赎，聊了自定义序列化器的巫毒魔法，还聊了 MessagePack 这种二进制猛兽。
序列化不仅仅是技术问题，它是架构问题。
当你开始使用 Map 代替普通对象来存储状态，当你开始使用 Immer 来保证引用的纯净，当你开始使用 structuredClone 来处理线程间的数据传递时，你会发现，跨端同步变得异常平滑。
不要害怕序列化。把它看作是一次“数据洗礼”。通过这次洗礼，你将去除掉那些脆弱的、依赖环境的、不可复用的代码，留下最纯粹的、最强大的、可移植的数据结构。
现在，拿起你的代码，去征服那些跨端的桥梁吧！
（讲座结束，掌声雷动）