Temporal.ZonedDateTime 通过绑定 IANA 时区标识符（如 'America/New_York'）并查内置时区数据库，显式校验时刻有效性，遇夏令时间隙（如2:00–2:59）直接抛 RangeError，避免静默错误；+08:00 是静态偏移，而 [Asia/Shanghai] 是动态时区，依时间点自动匹配历史/未来偏移；add() 保持原始时区推进时间，withTimeZone() 瞬时查目标时区偏移；其精度优势体现在纳秒支持、闰秒预留、日历解耦及强制显式处理，杜绝模糊输入。
Temporal.ZonedDateTime 为什么能避开“2:00 不存在”这类错误
传统 Date 在解析如 '2023-03-12T02:30:00-05:00' 这类字符串时，会静默跳过或回滚到邻近有效时间，结果不可预测；而 Temporal.ZonedDateTime.from() 遇到夏令时间隙（如美国东部时间 2:00–2:59 消失）会直接抛出 RangeError，明确提示“invalid time”。这不是缺陷，是精度保障——它强制你在代码里显式处理边界情况，而不是靠运气。
关键在于：它不依赖偏移量（-05:00）做计算，而是绑定 IANA 时区标识符（如 'America/New_York'），再查表确认该时刻是否真实存在。夏令时切换规则（起止日期、偏移变化）全部来自内置时区数据库，无需手动维护。
时区转换中 “+08:00” 和 “[Asia/Shanghai]” 的本质区别
只写 +08:00 是静态偏移，它无法表达“2026年上海是否实行夏令时”——事实上中国已多年不实行，但未来政策若变，+08:00 仍固定不变；而 [Asia/Shanghai] 是动态时区标识，Temporal 会根据时间点自动查表：对 2026-04-10 使用 +08:00，对 1986-05-04 则可能用 +09:00（历史夏令时），对 2099 年则按最新规则推演。
所以创建 ZonedDateTime 时必须带方括号时区名：
✅ 正确：Temporal.ZonedDateTime.from('2026-04-10T14:32:00+08:00[Asia/Shanghai]')
❌ 错误：Temporal.ZonedDateTime.from('2026-04-10T14:32:00+08:00')（抛 TypeError）
add() 和 withTimeZone() 对夏令时的响应差异
add() 是沿时间轴推进固定时长，全程保持原始时区上下文；withTimeZone() 是瞬时转换，会重新查目标时区在该 UTC 时刻的偏移。
- 从纽约出发（
America/New_York）飞 1 小时，到达时仍是纽约时间，哪怕刚好跨过 DST 切换点——add({hours: 1})不会“跳过”2:00，而是返回下一个合法本地时间（如 3:00） - 把同一时刻显示为伦敦时间：
zdt.withTimeZone('Europe/London')会立刻查 2026-04-10T15:32Z 在伦敦是 BST（+01:00）还是 GMT（+00:00），并给出对应本地时间
二者不能互换：前者是“飞行过程”，后者是“换表显示”。混淆会导致会议提醒提前/延后一小时。
为什么 Temporal 的精度优势常被低估
多数人只关注“能不能转成正确字符串”，却忽略更关键的隐性精度：纳秒级时间戳保留、闰秒预留字段、日历系统解耦（比如支持农历计算而不污染 Gregorian 逻辑）。这些不体现在 console.log 里，但在金融结算、卫星调度、跨历法日程同步等场景中，差一纳秒就可能触发重试或告警。
真正容易被忽略的是：Temporal 的所有操作都默认拒绝模糊输入。你无法绕过时区声明、无法跳过无效时间校验、无法隐式降级为本地时区——这种“不友好”，恰恰是精度的守门员。
