必须用 temporal 替代 date，跨时区逻辑须弃用 new date()；zoneddatetime.from() 必须传 iana 时区名（如 america/chicago）而非固定偏移；夏令时重叠/间隙需显式指定 disambiguation；比较和计算应统一转 instant；显示本地时间优先用 withtimezone('local') 而非 tolocalestring()。
不能“用 Temporal 修复 Date”，只能用 Temporal 替换 Date —— 所有跨时区、涉夏令时的逻辑，必须从 new Date() 彻底撤出。
Temporal.ZonedDateTime.from() 必须带 IANA 时区名，不能只传 +08:00
传 Temporal.ZonedDateTime.from('2024-11-03T01:30-05:00') 会失败，因为 -05:00 是静态偏移，不包含夏令时规则；而 Temporal.ZonedDateTime.from('2024-11-03T01:30-05:00[America/Chicago]') 才能查 tzdata 确认：此时是标准时间（-06:00）还是夏令时间（-05:00）。
- IANA 时区名（如
America/Chicago）才是“活”的——它绑定历史与未来所有偏移变更 - 仅传
+08:00或GMT+8的字符串，from()会抛SyntaxError或静默降级为PlainDateTime - 后端返回的 ISO 字符串若含偏移但无时区名（如
2024-11-03T01:30:00+08:00），需补全时区名再解析，例如：Temporal.Instant.from('2024-11-03T01:30:00+08:00').toZonedDateTimeISO('Asia/Shanghai')
夏令时重叠/间隙时刻必须显式声明 disambiguation 策略
2024-11-03 凌晨 1:30 在 America/Chicago 是重叠时刻（标准时间开始，同一本地时间出现两次），ZonedDateTime.from() 默认用 disambiguation: 'compatible'（取后一个偏移，即 -06:00），但业务可能需要前一个（如用户明确选“夏令时结束前”）。
- 显式传参：
Temporal.ZonedDateTime.from('2024-11-03T01:30[America/Chicago]', { disambiguation: 'earlier' }) - 间隙时刻（如 2026-03-09 凌晨 2:15 在
America/New_York）会直接抛RangeError: invalid time，不可忽略 - 表单接收用户输入的“本地时间 + 时区”时，绝不能直接
from()字符串，应先用PlainDateTime.from()解析日历部分，再调用.withTimeZone(timeZoneId, { disambiguation })
跨时区比较和计算必须统一到 Instant
ZonedDateTime.equals() 比较的是“是否完全相同对象”，不是“是否同一物理时刻”；两个不同 timeZone 的 ZonedDateTime 即便指向同一秒，equals() 也返回 false。
- 做时间比较（如判断会议是否已开始）：用
zdt1.getEpochNanoseconds() === zdt2.getEpochNanoseconds() - 做定时任务调度或倒计时：先转
Instant，加减用Duration，再按需转回目标时区显示 - 错误写法：
zdt.add({days: 1})在夏令时切换日可能导致结果比预期早/晚一小时（因按日历语义而非恒定毫秒）；正确做法：zdt.toInstant().add({days: 1}).toZonedDateTimeISO(targetTimeZone)
前端显示本地时间别用 toLocaleString()，改用 withTimeZone('local')
toLocaleString() 行为受浏览器语言、区域设置、甚至系统时钟同步状态影响，不可控；而 zdt.withTimeZone('local') 明确走 Temporal 内置时区逻辑，且结果可预测。
-
zdt.withTimeZone('local').toString()输出格式稳定（ISO 8601 带本地偏移和时区名） - 若需自定义格式（如 “上午 9:30”），再用
toLocaleTimeString()，但仅限最终展示层，绝不用于计算或存储 - 注意：
'local'是运行时系统默认时区，不是用户手动选的时区；用户选择的时区（如Europe/Berlin）必须显式传入withTimeZone()
最易被忽略的一点：Temporal 不处理闰秒，所有 Instant 都在平滑 UTC 时间线上；如果你的业务真要对齐原子钟授时（比如金融高频交易时间戳对账），得自己维护闰秒表并手动补偿——但绝大多数全球化应用，这个“忽略”恰恰是优势，不是缺陷。
