Temporal.Duration 不能直接用于工时计算，因为它仅表示物理时间差，不处理时区、工作日、午休、节假日或业务时段等语义规则，必须配合 Temporal.PlainDateTime、ZonedDateTime 及自定义逻辑分步实现。
Temporal.Duration 不能直接用于工时计算——它不处理时区、工作日、午休或业务规则，只做纯时间跨度的加减。想算“8小时工作制下的实际工时”，得自己组合 Temporal.PlainDateTime、Temporal.ZonedDateTime 和逻辑判断。
为什么不能直接用 Temporal.Duration 算工时
它本质是“物理时间差”的容器：比如 1d 3h 45m，但不会告诉你这1天是否包含周末、是否跨节假日、是否在9:00–18:00工作时段内。Excel 里的 NETWORKDAYS.INTL 或 MOD(...,1) 能解决的业务语义问题，Temporal.Duration 全部回避。
常见误用现象：
• 把两个 ZonedDateTime 相减得到 Duration，就以为得到了“有效工时”
• 用 duration.total({ unit: 'hour' }) 得到 27.75，然后直接乘以 hourly rate —— 实际可能只该算 8 小时（当天工作上限）或 0 小时（周日）
-
Temporal.Duration没有“工作日”概念，也不识别holidays数组 - 它不感知
TIME(8,0,0)这类业务约束，无法自动截断超时部分 - 跨时区场景下，
Duration是绝对秒数，但“工时”往往按本地工作时段定义
真正要用 Temporal.Duration 的地方
它适合做“中间态”或“辅助态”计算：比如记录任务从启动到完成的原始耗时、计算两次 API 调用间隔、对齐日志时间戳偏差。
典型安全用法：
- 用
start.since(end)得到Duration，再调用.total({ unit: 'millisecond' })做性能埋点 - 把
Duration存进数据库字段（类型为INTERVAL），避免日期解析歧义 - 和
Temporal.PlainTime配合做“班次时长校验”：比如夜班排班表里写“22:00–06:00”，可用PlainTime.from('22:00').until(PlainTime.from('06:00'))得到{ hours: 8 }，但注意这个 8 不含日期逻辑，仅作模板验证
替代方案：用 Temporal.PlainDateTime + 自定义逻辑
要算“2026-05-06 09:30 到 2026-05-08 16:20 的标准工时（双休+法定假日）”，必须分步走：
- 先用
Temporal.PlainDateTime解析起止时间（剥离时区，聚焦业务日） - 遍历每一天，用
getDayOfWeek()过滤周六（7）、周日（1），查表排除['2026-05-01', '2026-10-01']等假日 - 对每个有效工作日，用
PlainTime计算当日实际覆盖段：比如 09:30–17:00 和 09:00–12:00 取交集 - 每段结果转成
Duration，最后sum()得总工时（单位：毫秒或分钟）
示例片段（伪代码）：
const start = Temporal.PlainDateTime.from('2026-05-06T09:30');
const end = Temporal.PlainDateTime.from('2026-05-08T16:20');
const workStart = Temporal.PlainTime.from('09:00');
const workEnd = Temporal.PlainTime.from('17:00');
// ...（循环 day-by-day，取交集，累加 duration）
别试图用 Duration 一步到位——它没这个设计目标。
容易被忽略的关键点
最常漏掉的是“午休剔除”。哪怕你用了 Temporal，也得手动处理 12:00–13:00 这一小时断点。没有现成函数能自动拆分 09:00–16:30 成 09:00–12:00 + 13:00–16:30；Duration 更不会帮你做这事。
另一个隐形坑：Temporal.Duration.from({ hours: 8.5 }) 会变成 { hours: 8, minutes: 30 }，但如果你传入 { hours: 8.75 }，它不会四舍五入或报错，而是存成 { hours: 8, minutes: 45, seconds: 0 } —— 表面没问题，可一旦后续用 total('minute')，精度误差会累积。
