temporal.duration 不支持直接表示“3个月又15天”的混合单位，需通过 temporal.plaindate.add() 分步执行：先加月再加日，自动处理月末归约与闰年，确保业务语义明确且安全。
Temporal.Duration 目前不支持直接表示“3个月又15天”这类混合单位的精确业务周期，因为它设计上严格区分“日历单位”（年、月、日）和“时间单位”（小时、分钟、秒、毫秒），而“月”在日历中长度不固定（28–31天），无法无歧义地转换为固定毫秒数。因此，所谓“优雅计算”不是靠 Duration 本身完成，而是靠 Temporal.PlainDate / PlainDateTime 与 Duration 的协同使用，并明确业务语义。
理解 Temporal.Duration 的定位：它不处理日历逻辑
Temporal.Duration 实例（如 { months: 3, days: 15 }）只是数据容器，不自带加减行为。你不能直接用它对日期做“+”，必须通过 add() 或 subtract() 方法作用于 PlainDate 等日历类型：
-
Temporal.PlainDate.from('2024-01-10').add({ months: 3, days: 15 })→2024-04-25 - 这个操作是“先加3个月（到4月10日），再加15天（到4月25日）”，顺序固定，不可逆
- 如果起始日不存在（如 2024-01-31 + 1 month），会自动归约到当月最后一天（2024-02-29）
“3个月又15天”的业务含义需明确定义
不同场景下，“3个月又15天”可能指：
- 滚动周期：从签约日开始，先跳3个完整日历月，再推15个自然日（推荐用于合同期、订阅续期）
- 固定偏移：始终是“当前月+3，日+15”，若溢出则进位（如 2024-01-25 → 2024-04-40 → 归约为 2024-05-10）
- 工作日感知：排除周末/节假日（这已超出 Temporal 原生能力，需额外逻辑）
Temporal 默认采用第一种——即“先月后日”的逐级归约策略，符合大多数财务与法务场景。
安全执行跨月加法的推荐写法
避免直接传入混合对象导致语义模糊，显式拆解步骤更可控：
const start = Temporal.PlainDate.from('2024-01-10');
// ✅ 推荐：分步 + 显式检查
const afterMonths = start.add({ months: 3 });
const result = afterMonths.add({ days: 15 });
// ⚠️ 不推荐：单次传入混合对象（虽可行，但可读性差）
// start.add({ months: 3, days: 15 })
- 分步调用便于插入校验（例如检查
afterMonths是否落在节假日） - 每步都返回新实例，天然不可变，适合函数式链式处理
- 若需反向计算（如到期日倒推），用
subtract()同样分步即可
注意边界情况：月末日期与闰年
Temporal 的归约规则很务实：
-
2024-01-31.add({ months: 1 })→2024-02-29（2月无31日，取最后一天） -
2024-01-31.add({ months: 1, days: 1 })→ 先得 2024-02-29，再 +1 天 →2024-03-01 - 闰年 2月29日参与运算时，一切照常，无需特殊处理
这种行为不是 bug，而是为保障业务连续性做的合理兜底——比抛错或静默失败更可靠。
