JSON序列化Date对象具有单向性：stringify转为ISO字符串后，parse无法自动还原为Date实例，仅得普通字符串，需手动用new Date()恢复。
识别 JSON 序列化中 Date 对象自动转字符串的单向性陷阱，关键在于理解 JSON.stringify() 和 JSON.parse() 的行为不对称：Date 实例在序列化时被自动转为 ISO 字符串，但反序列化后只是普通字符串，不再具备 Date 行为。
看序列化输出是否丢失类型信息
执行 JSON.stringify({ time: new Date() })，结果类似：{"time":"2026-05-07T04:10:00.123Z"}
注意——引号内的值是字符串，不是 Date 对象。只要看到时间值被双引号包裹、且没有 new Date(...) 包裹，就说明类型已丢失。
检查反序列化后的值是否仍可调用 Date 方法
对上述字符串执行 JSON.parse() 后，验证：
-
typeof data.time === 'string'→ 是 true，说明不是对象 -
data.time.getMonth→undefined（报错或返回 undefined） -
data.time instanceof Date→false
留意常见误判场景
以下情况容易让人误以为“它还是 Date”：
- 控制台打印
data.time显示类似Fri May 07 2026...—— 这只是浏览器对 ISO 字符串的友好格式化，不代表它是 Date 实例 - 后端返回字段名含
time、created_at等语义提示 —— 名称不改变数据本质，仍需手动恢复 - 使用
new Date(data.time)成功构造了新 Date —— 这属于主动修复，不是 JSON 自动还原
提前预防：统一约定 + 显式处理
避免依赖自动行为，从源头建立识别习惯：
- 前后端文档中标注哪些字段应为 Date 类型（如
"created_at": "string (ISO 8601)"） - 前端收到响应后，用工具函数批量恢复：
parseDateFields(obj, ['created_at', 'updated_at']) - 序列化前主动转格式：
date.toISOString()或date.getTime()，保持语义清晰
