用ZonedDateTime进行跨国时区转换，关键在于保持同一物理瞬间并自动适配地理时区规则（含夏令时），必须使用ZoneId（如"Europe/London"）而非固定ZoneOffset；跨时区转换只用withZoneSameInstant()，解析输出需带完整时区ID（如"Asia/Tokyo"），警惕DST边界日的异常时间。
用 ZonedDateTime 解决跨国系统时区转换，关键不是“换数字”，而是守住同一物理瞬间，并让系统自动响应地理时区规则——尤其是夏令时切换。
必须用 ZoneId，别碰 ZoneOffset
固定偏移（如 ZoneOffset.of("+08") 或 "GMT+1"）是死的：它永远 +8 小时或 +1 小时，不管伦敦今年 3 月是否已切夏令时（UTC+1），也不管 10 月是否已退回（UTC+0）。而真实业务场景里，“伦敦时间”本身就在变。
- ✅ 正确：用 ZoneId.of("Europe/London") —— 内置 IANA 规则库，自动查表适配 DST
- ✅ 正确：用 ZoneId.of("Asia/Shanghai") —— 虽无夏令时，但明确地理上下文，避免和 "UTC+8" 混淆
- ❌ 错误：用 ZoneOffset.ofHours(8) 或 ZoneId.of("GMT+8") —— 不代表任何真实地区，无法用于跨时区可信转换
跨时区转换只用 withZoneSameInstant()
用户在东京选了“2026-06-15 14:00 开会”，你得准确告诉纽约同事那是当地几点。这不是加减几个小时的事，而是同一瞬时在不同规则下的自然表达。
- 调用 zdt.withZoneSameInstant(ZoneId.of("America/New_York"))，底层基于 Instant 对齐，自动套用纽约当前偏移（6 月属 EDT，UTC−4）
- 结果自然体现差异：东京 UTC+9 → 纽约 UTC−4，差 13 小时；若换成 12 月查询，则纽约为 EST（UTC−5），差 14 小时
- ⚠️ 绝对不用 withZoneSameLocal()：它强行保留 “14:00” 这个数字，会导致时间点漂移，逻辑错误
解析和输出必须带完整时区 ID
字符串里只写 "+08:00" 或缩写如 "CST" 是高危操作：前者丢失地理含义，后者歧义（China？Central？Cuba？）。
- ✅ 安全解析：输入格式应为 "2026-06-15T14:00:00[Asia/Tokyo]" —— 方括号内是真实时区名，ZonedDateTime 能据此查规则
- ✅ 推荐输出：用 DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS VV")，生成类似 "2026-06-15 14:00:00.000 Asia/Tokyo" 的可读、可解析、无歧义结果
- ❌ 避免输出仅含偏移的 ISO 格式（如 "...+09:00"），它无法反向还原原始时区意图
警惕夏令时边界日的“不存在”与“重复”时间
每年春秋季切换日凌晨，某些本地时间会消失或出现两次。例如 2026-03-29 柏林凌晨 2:00–2:59 不存在（钟从 02:00 直跳 03:00）；2026-10-26 则 02:00–02:59 会出现两次。
- ZonedDateTime 默认遇到“不存在时间”直接抛 DateTimeException，强制你在录入/解析环节处理，而不是静默错位
- 若需容错，可用 withEarlierOffsetAtOverlap() 或 withLaterOffsetAtOverlap() 显式指定取哪个偏移
- 所有用户输入的时间，必须绑定原始时区 ID 构造 ZonedDateTime，不能先转成毫秒再“猜”时区
