temporal.timezone 是同步对象，异步处理关键是在异步流程中正确集成它：先获取用户真实时区（如通过 api），用 timezone.from() 验证并缓存；时间源统一用 temporal.instant（utc）锚定，再按需转本地化时间；避免隐式依赖本地时区，夏令时调度需显式校验。
Temporal.TimeZone 本身是同步对象，不提供异步方法——它不涉及网络、I/O 或等待操作。所谓“异步处理日期偏移与显示”，实际是指在异步业务流程中（如 API 请求、用户时区探测、配置加载）安全、准确地集成 TimeZone 和其他 Temporal 类型，避免因时区逻辑混入异步链而引发漂移或竞态。关键不在“TimeZone 异步”，而在“如何在异步上下文中正确使用 TimeZone”。
先获取用户真实时区，再构造 TimeZone 实例
浏览器的 Intl.DateTimeFormat().resolvedOptions().timeZone 是同步且可靠的，但若需从后端接口动态拉取用户偏好时区（如数据库存储的 "Europe/Paris"），就得在 Promise 链中处理：
- 不要在异步回调里直接 new Date() 或用系统本地时区推算“今天”，那会丢失用户上下文
- 拿到时区字符串后，立即用
Temporal.TimeZone.from(timeZoneId)验证合法性（非法 ID 会抛RangeError） - 推荐缓存已验证的 TimeZone 实例，避免重复解析同一字符串
用 Instant 锚定时间点，再通过 TimeZone 转换显示
全球业务的时间源应统一为 UTC 瞬时点（Temporal.Instant），它不随环境变化，适合跨异步阶段传递：
- API 响应中的
"2026-04-30T13:22:15.123Z"可直接转为Temporal.Instant.from() - 在 React 组件 useEffect 或 Vue onMounted 中，用该 Instant 调用
.toZonedDateTimeISO(userTimeZone)获取本地化时间 - 这样即使组件多次重渲染、时区配置异步更新，只要 Instant 不变，转换结果就确定可重现
避免在异步中间件里隐式依赖本地时区
常见陷阱：日志中间件、请求拦截器、表单提交处理器中调用 new Date().toLocaleString() 或 Date.now() —— 这些值取决于服务器或浏览器本地设置，不是用户视角：
- 替换为
Temporal.Now.instant()获取标准 UTC 时间戳 - 若需记录“用户提交时刻的本地时间”，必须显式传入其时区：
instant.toZonedDateTimeISO('Asia/Tokyo').toString() - 服务端 Node.js 环境尤其要注意：Docker 容器默认 TZ=UTC，
new Date()的 toString() 显示的是 UTC，不是用户所在地时间
夏令时切换期的异步任务调度要显式校验
当定时任务基于用户本地时间触发（如“每天东京时间上午9点推送”），不能只靠 setTimeout 或 cron 表达式硬编码偏移：
- 每次调度前，用
Temporal.PlainDateTime.from({ hour: 9, minute: 0 })和userTimeZone构造 ZonedDateTime - 调用
.getEpochMilliseconds()转为毫秒时间戳，交给 setTimeout；或用next()方法计算下一次合法时刻（自动跳过夏令时间隙） - 对无效时间（如美国东部时间 2:30 在 3 月第二个周日凌晨），
ZonedDateTime.from()会明确报错，迫使你在异步流程中加入 fallback 处理逻辑
