Temporal.Duration 不涉及时区，仅表示固定长度时间量；计费时段必须先转为 Temporal.Instant 再计算差值，避免日历语义陷阱。
Temporal.Duration 本身不涉及时区，它只是纯粹的“时间量”——比如 3 天、2 小时、45 分钟。任何试图用 Duration 直接处理“跨时区计费时段”的逻辑，都会掉进日历语义陷阱。真正要做的，是把“计费起止时间”先统一到 Temporal.Instant，再用 Duration 做差值计算。
Duration 不该参与时区转换，只负责纯时间量运算
Temporal.Duration 没有时区概念，它的 .total()、.add()、.subtract() 全部基于固定长度单位（1 天 = 86400 秒，不因 DST 变动）。所以：
- 不能用
zdt1.until(zdt2, { largestUnit: 'hour' })得到“用户实际占用小时数”——它返回的是日历小时（可能含夏令时跳变），不是物理秒数 - 不能对
ZonedDateTime直接调用.add(duration)来推算“计费结束时间”，除非你明确接受日历加法（例如“加 24 小时”在 DST 切换日可能变成 23 或 25 小时） - 正确路径是：先把两个带时区的时间转成
Instant，再用instantEnd.since(instantStart)得到精确纳秒级Duration
计费起止时间必须用 Instant 对齐，而非 ZonedDateTime 比较
假设用户在 America/Chicago 本地时间 2026-03-09T01:30 开始使用服务，系统记录的是其本地时间 + 时区 ID。此时不能直接构造 ZonedDateTime 后相减：
const zdtStart = Temporal.ZonedDateTime.from('2026-03-09T01:30[America/Chicago]'); // ⚠️ 这是间隙时刻，会抛 RangeError
而应走安全路径：
- 前端提交时，把用户选择的“本地时间 + 时区”拆解为
PlainDateTime和timeZoneId，再显式指定disambiguation - 后端用
PlainDateTime.from('2026-03-09T01:30').withTimeZone('America/Chicago', { disambiguation: 'compatible' })构造视图 - 立刻转为
.toInstant()，得到唯一物理时刻 - 所有计费时长计算、阈值判断、账单生成，全部基于
Instant差值
按分钟计费场景下，Duration.total({ unit: 'minute' }) 的精度陷阱
Duration.total({ unit: 'minute' }) 返回的是浮点数，且受纳秒舍入影响。例如 59 分 59.999 秒会向下取整为 59 分钟，导致少计费。
- 推荐用
instantEnd.since(instantStart).total({ unit: 'nanosecond' })获取纳秒总数，再手动除以 60_000_000_000（每分钟纳秒数）并Math.floor或Math.ceil，取决于你的计费策略（向上取整还是向下取整） - 避免链式调用：
duration.total('hour').total('minute')是错的——total('hour')返回浮点小时，再转分钟会放大误差 - 若需展示“X 小时 Y 分钟”，用
duration.round({ smallestUnit: 'minute' }).getFields()更可靠
最易被忽略的一点：计费规则里的“30 分钟免费”或“每 15 分钟一档”，本质是对物理时间的切片，和用户所处时区无关。只要起止时间进了 Instant，后续所有计算就脱离了地理语义——这才是 Temporal 能帮你守住的底线。
