temporal.plaindate专用于纯日期表示，不涉及时区，避免date的隐式偏移问题；正确用法为from('yyyy-mm-dd')，不可与date混用或调用时区方法。
Temporal.PlainDate 不会参与任何时区计算，它只表示“日历上的某一天”，所以只要你的业务逻辑只需要日期（比如生日、合同生效日、报表周期），用它就能天然避开 Date 在序列化、跨时区解析、toISOString()、toString() 等环节引发的隐式本地时区偏移问题。
为什么 new Date('2024-01-01') 在东京和纽约输出不同？
因为 Date 构造函数对形如 'YYYY-MM-DD' 的字符串，默认按 UTC 解析，但调用 .toString() 或 .toLocaleDateString() 时又自动转成本地时区显示——这导致同一字符串在不同时区机器上产生歧义。例如：new Date('2024-01-01') 在纽约是 Sun Dec 31 2023 19:00:00 GMT-0500，表面看就错了。
而 Temporal.PlainDate.from('2024-01-01') 永远就是“2024 年 1 月 1 日”，不绑定毫秒，不关联时区，没有 toString 隐式转换。
- ✅ 正确用法：
Temporal.PlainDate.from('2024-01-01')、Temporal.PlainDate.from({ year: 2024, month: 1, day: 1 }) - ❌ 错误习惯：拿
Temporal.PlainDate去跟Date实例直接比较、或试图调用.getTimezoneOffset()——它根本没时区属性 - ⚠️ 注意：
Temporal.PlainDate.from(new Date())是合法的，但它会丢弃时间部分并按本地时区推算“今天是哪天”，不是无损转换
PlainDate 和 PlainDateTime、ZonedDateTime 的分工边界在哪？
三者定位完全不同：PlainDate 只管年月日；PlainDateTime 多了时分秒（仍无时区）；ZonedDateTime 才真正承载带时区的时间点。混用就会出错。
- 生日字段、财务月结日、节假日配置 → 用
Temporal.PlainDate - 会议预约（需精确到秒，但不指定时区）→ 用
Temporal.PlainDateTime，后续再绑定时区 - 用户下单时间、日志打点、API 返回的时间戳 → 必须用
Temporal.ZonedDateTime或Temporal.Instant - ⚠️ 常见坑：
plainDate.with({ hour: 14 })会报错，因为PlainDate没有hour字段；要加时间得先升格为PlainDateTime
后端 API 交互中如何安全收发 PlainDate？
JSON 本身不支持原生日期类型，所以你必须约定字符串格式。推荐统一用 ISO 8601 日期格式 'YYYY-MM-DD'，这是 Temporal.PlainDate.toString() 的默认输出，也是它的唯一标准序列化方式。
- ✅ 序列化发送：
user.birthday.toString()→'1990-05-23' - ✅ 反序列化接收：
Temporal.PlainDate.from(json.birthday)，能自动识别字符串或对象输入 - ❌ 不要用
JSON.stringify(new Date())后再截取前 10 位，那依赖Date的实现细节，且无法验证合法性 - ⚠️ 服务端若用 Java/Python，需确认其 Temporal 兼容库是否支持
PlainDate的纯日期解析（例如 Java 21+ 的java.time.LocalDate是等价物）
最易被忽略的一点：PlainDate 的 .equals() 是浅比较，但如果你从用户输入拼接了年月日字段再构造，务必确保 month 是 1–12、day 在当月有效范围内——Temporal.PlainDate.from({ year: 2024, month: 2, day: 30 }) 会静默归一化为 2024-03-01，而不是报错。业务关键路径上建议加 isValid 校验或用 from 的 try/catch 包裹。
