JSON.parse 的 reviver 无法实现强类型校验，因其仅处理 JSON 标准类型，丢失原型、函数、Date 等信息，且 TypeScript 类型在运行时不存在；应改用解析后校验（如 Zod）与显式重建。
JSON.parse 配合 reviver 无法实现真正意义上的“强类型校验”，因为它本质上只处理字符串到 JavaScript 值的解析，且会丢失原型、函数、undefined、Symbol、Date、RegExp 等非 JSON 可序列化类型。reviver 的作用是逐层转换已解析出的值，但它运行在 JSON 解析完成之后，此时原始结构已扁平化为纯数据对象，原始类型信息（如 class 构造器、TypeScript 类型注解）早已不可见。
为什么 reviver 不适合做强类型校验
reviver 函数接收的是 key 和 value，而 value 已是 JSON 解析后的结果（仅限 null、boolean、number、string、object、array）。它无法得知：
- 该字段原本应是 Date 实例还是字符串时间戳
- 某个 number 字段是否本应是枚举字面量（如 Status.Active）
- 某个 object 是否应属于特定 class（如 User 类），因为 class 信息未进入 JSON 字符串
- TypeScript 类型在运行时完全不存在，reviver 拿不到任何类型元数据
可行的替代方案：解析后校验 + 显式重建
若需保障深拷贝副本符合预期结构与类型约束，推荐分两步走：
- 先安全解析：用 JSON.parse(..., reviver) 做基础清洗（如过滤敏感字段、转义字符串），但不依赖它做类型断言
- 再显式校验与重建：使用类型守卫（type guard）、Zod、Yup 或自定义校验函数验证解析结果，并按需构造带原型/方法的对象
例如用 Zod 校验并保证类型：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
id: z.number().int().positive(),
name: z.string().min(1),
createdAt: z.string().datetime()
});
const raw = '{"id":123,"name":"Alice","createdAt":"2024-01-01T00:00:00Z"}';
const parsed = JSON.parse(raw);
const user = userSchema.parse(parsed); // 运行时校验，失败抛错
// user 是严格符合 schema 的对象，类型为 z.infer
若必须保留类实例，需额外序列化/反序列化逻辑
要让深拷贝副本具备原始类的方法和行为，不能只靠 JSON.parse。需要约定序列化格式（如添加 $$type 字段），并在 reviver 中识别并重建：
constructor(public id: number, public name: string) {}
greet() { return `Hello, ${this.name}`; }
toJSON() {
return { $$type: 'User', id: this.id, name: this.name };
}
}
// 序列化时：
const json = JSON.stringify(new User(42, 'Bob')); // {"$$type":"User","id":42,"name":"Bob"}
// 反序列化时：
JSON.parse(json, (key, value) => {
if (value?.['$$type'] === 'User') {
return new User(value.id, value.name);
}
return value;
});
注意：这要求你完全控制序列化过程，并手动维护类型映射，不是通用强类型校验，而是有约定的类型重建。
小结：reviver 的定位是数据转换，不是类型系统
它适合做轻量清洗（如把字符串 'null' 转成 null、统一日期格式、剔除空字段），但不应承担类型安全职责。真正的强类型保障需结合：
- 静态类型检查（TypeScript 编译期）
- 运行时 Schema 校验（Zod/Yup/io-ts）
- 必要时的手动类重建逻辑
把类型校验逻辑从 reviver 中解耦出来，代码更清晰、可测、可维护。
