json 不识别日期类型，date 对象序列化为 iso 字符串后丢失类型信息，解析结果仅为字符串而非 date 实例，导致无法调用日期方法；且无自动时区处理与格式语义保留机制，需手动转换与约定字段规范。
JSON 方法本身不识别日期类型，这是最核心的局限——JSON.stringify() 会把 Date 对象转成 ISO 字符串（如 "2026-06-23T06:23:00.123Z"），而 JSON.parse() 默认只还原为字符串，不会变回 Date 实例。这意味着你拿到的“日期”只是普通字符串，无法直接调用 getFullYear()、getTime() 等方法，一用就报错。
日期被序列化成字符串后丢失类型信息
当一个对象含 new Date() 属性时：
-
JSON.stringify({ time: new Date('2026-06-23') })输出{"time":"2026-06-23T00:00:00.000Z"}—— 日期已固化为 UTC 字符串； -
JSON.parse('{"time":"2026-06-23T00:00:00.000Z"}').time是字符串，不是 Date 对象； - 若未手动转换，后续所有日期计算（如加一天、比较大小）都会失败或结果错误。
时区与本地时间表达不一致
ISO 字符串默认以 UTC 表示（末尾带 Z），但业务常需展示用户本地时间：
- 服务器返回
"2026-06-23T14:30:00Z"，客户端直接显示会变成本地时区的凌晨或下午，取决于系统设置； - 没有自动机制区分“存储用 UTC”和“展示用本地”，开发者必须显式处理时区转换；
- 若原始 Date 是本地构造（如
new Date("2026-06-23")），再 stringify 后可能隐含本地偏移（如+08:00），解析后仍无 Date 行为。
无法保留自定义格式或上下文语义
JSON 是纯数据交换格式，不承载格式意图：
- 你希望字段
createdAt永远按yyyy-MM-dd HH:mm:ss显示，但 JSON 不保存这个规则； - 字段名如
deadline或publishedAt在 JSON 中只是键名，没有语义标签，无法触发自动格式化逻辑； - 像
YYYY-MM-dd和yyyy-MM-dd这类大小写敏感的格式含义（ISO 周年 vs 日历年），JSON 更是完全不感知。
缺乏反序列化钩子，需手动修复
浏览器原生 JSON API 不提供解析时的类型恢复机制：
- 不能像后端 Jackson 或 C# Newtonsoft 那样通过注解或转换器自动将字符串转 Date；
- 常见做法是在
JSON.parse()后遍历对象，用正则识别 ISO 格式字符串并 new Date() 转换，但易漏判、误转（比如把纯数字 ID 当日期）； - 更稳妥的方式是约定字段命名规范（如所有以
At结尾的字段视为日期），或在传输层使用带类型元信息的协议（如 Protocol Buffers），而非裸 JSON。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
