用 Date 做跨时区历史数据统计必然误差，必须用 Temporal.Instant 存原始时间点、Temporal.ZonedDateTime 做时区切片；因 Date 内部毫秒数依赖本地时区构造，导致同一字符串在不同时区解析出不同 UTC 时间，且无法还原原始时区上下文。
直接结论：用 Date 做跨时区历史数据统计，误差不是“可能”，而是“必然”——它连“2024-11-03 01:30 在 Chicago 是标准时间还是夏令时”都答不上来，更别说回溯五年订单日志。必须用 Temporal.Instant 存原始时间点，Temporal.ZonedDateTime 做带时区切片，彻底切断本地时区对历史数据的污染。
为什么 Date 统计历史数据一定会偏移
根本原因在于 Date 内部只存毫秒数，且这个毫秒数是「构造时刻按浏览器本地时区反推出来的 UTC 时间」。比如你在东八区执行 new Date('2020-03-08T10:00')，它会先当成本地时间（即 UTC+8），再转成毫秒数 1583632800000；但同一字符串在西五区执行，会被当成 UTC−5，毫秒数变成 1583665200000——两个不同值，指向完全不同的 UTC 时刻。
更致命的是：历史数据入库时若用 Date.toISOString()，看似是 UTC，实则依赖构造逻辑；而读取时若用 new Date(utcString)，又会强制转回本地时区显示，中间已丢失原始上下文。
- 数据库里存的是
"2020-03-08T10:00:00.000Z"，但它的来源可能是东八区用户填的“上午10点”，也可能是西五区用户填的“上午10点”，二者实际 UTC 时间差 13 小时 -
Date.prototype.getTimezoneOffset()返回的只是“此刻”的偏移，对 2020 年某天毫无意义 - 调用
date.toLocaleDateString({ timeZone: 'Asia/Shanghai' })无法还原原始意图，它只是把当前毫秒数“重渲染”一遍
用 Temporal.Instant 替代 Date 存原始时间戳
Temporal.Instant 是唯一该用于存储和计算的类型：它只表示时间线上的一个精确点，不绑定日历、不涉及时区、不可变、纳秒精度、无视闰秒。所有统计逻辑（如“过去7天订单数”“超时未支付订单”）必须基于它做减法或比较。
示例：从后端拿到 ISO 字符串，直接转为 Instant
const instant = Temporal.Instant.from('2020-03-08T10:00:00Z');
注意：Instant.from() 接受任何符合 ISO 8601 的 UTC 字符串（含 Z 或 +00:00），拒绝模糊输入（如无时区的 '2020-03-08T10:00' 会抛 RangeError）。
- 入库前：统一用
instant.toString()得到标准 UTC 字符串（如"2020-03-08T10:00:00Z"），存数据库字段 - 查询后：用
Temporal.Instant.from(dbValue)还原，绝不用new Date()桥接 - 计算间隔：用
instant2.since(instant1)，返回Duration，结果恒定、可预测
用 Temporal.ZonedDateTime 切片历史数据（按本地日/周/月）
统计“上海门店每日营业额”，不能按 UTC 日切分（UTC 0 点 ≠ 上海 0 点），也不能靠 Date 的 getMonth()（它返回的是本地时区月份）。必须用 ZonedDateTime 显式绑定 IANA 时区，在该时区上下文中提取日历单元。
示例：把某个 Instant 转为上海本地日粒度标识
const zdt = instant.toZonedDateTimeISO({ timeZone: 'Asia/Shanghai' });
const dateKey = `${zdt.year}-${zdt.month.toString().padStart(2,'0')}-${zdt.day}`; // "2020-03-08"
- 切片逻辑必须写死时区（如
'Asia/Shanghai'），不能用'local'，否则部署到海外服务器就错乱 - 避免用
zdt.add({ days: 1 })做循环——夏令时切换日可能导致跳过或重复某天；改用instant.add({ days: 1 }).toZonedDateTimeISO(...) - 查“上周一至周日”这种范围，先算出 UTC 时间点，再转成目标时区的
ZonedDateTime提取dayOfWeek，再反推边界
旧系统迁移时最容易踩的坑
最危险的操作，是把 Date 实例当 Instant 用。例如：
const legacyDate = new Date('2020-03-08T10:00:00Z');
const instant = Temporal.Instant.from(legacyDate.toString()); // ❌ 错！toString() 已被本地时区污染
// 正确做法：
const instant = Temporal.Instant.from(legacyDate.toISOString()); // ✅ 仅当 legacyDate 确实来自 toISOString()
- 不要信任任何
Date.prototype.toString()、toLocaleString()输出，它们全是本地化陷阱 - 如果数据库里存的是
Date构造出的字符串（如"2020-03-08T10:00:00.000Z"），需确认它是否真来自toISOString()；若来自toString()，必须结合客户端时区字段重建 - 前端表单提交“日期+时间”字段时，别用
input[type="datetime-local"]的 value（它不带时区），改用PlainDateTime.from({ year, month, day, hour, minute })+ 用户选择的时区显式构造ZonedDateTime
真正难的不是写对第一行 Temporal.Instant.from()，而是确保整个数据链路——从用户输入、API 传输、数据库存储、后台计算、再到前端展示——每一环都放弃对 Date 的隐式依赖。一旦某处偷偷用 new Date() 解析字符串，历史统计的准确性就归零了。
