PHP DateInterval 如何计算订阅到期日：月末溢出、invert 与比较边界

订阅系统最容易被忽略的一类问题，是“一个月后到期”并不总等于加上固定天数。PHP 里用 DateTimeImmutable 和 DateInterval 表达续费周期时，月末日期、负向间隔和比较基准必须分开处理，否则 1 月 31 日续费可能落到 3 月，退款或撤销逻辑也可能把方向判断反过来。

先把业务规则说清：月周期按日历月推进，遇到不存在的目标日要明确采用月末回退；负向间隔只表示方向，最终到期判断仍应比较两个不可变时间点。

订阅到期日为什么会从 1 月 31 日跳到 3 月

PHP 的日期加法遵循日历规则：从 1 月 31 日加一个月时，目标月份先进入 2 月，但 2 月没有 31 日，继续规范化后可能落到 3 月。这个结果符合日期库的进位逻辑，却不一定符合“按月续费”的产品约定。

因此实现不能只写 $start->add(new DateInterval('P1M'))。更稳定的做法是保存原始日号，先把日期移动到目标月的第一天，再用目标月天数限制日号。

把月周期拆成可核对的计算边界

下面的函数只负责计算“按月且月末回退”的结果，不修改传入的起始对象：

format('j');
    $target = $start->modify('first day of next month');
    $lastDay = (int) $target->format('t');

    return $target->setDate(
        (int) $target->format('Y'),
        (int) $target->format('n'),
        min($day, $lastDay)
    );
}

这里的 first day of next month 是定位目标年月，format('t') 是读取该月最大日号，min() 才是“月末回退”这一业务规则。把三个动作拆开，日志和测试都能准确指出偏移发生在哪一层。

DateInterval 的 invert 如何影响撤销与退款判断

DateInterval 可以携带 invert，表示间隔方向为负。例如两个时间点相减后，间隔对象可能代表“向前一段时间”。但它不是一个可以直接替代 DateTimeImmutable 比较的布尔值：是否过期，仍应把当前时间与到期时间放到同一时区后比较。

把方向表达和到期判断分成两条线

= $expiresAt;
$remaining = $now->diff($expiresAt);

if ($remaining->invert === 1) {
    $isExpired = true;
}

比较表达式给出最终业务状态，diff() 负责生成可展示的剩余时间。两者都基于同一时区和同一组不可变对象，既能防止展示文案与状态不一致，也能避免在调试时把 invert 误读成“接口调用失败”。

上线前的日期边界门禁

• 用 1 月 31 日、2 月末、4 月 30 日分别核对月末回退。
• 固定时区后再比较 $now 与 $expiresAt，不要混用服务器默认时区。
• 确认续费计算返回新对象，原始开始时间仍可用于审计。
• 对已过期、恰好到期和尚未到期分别断言，不只测试正常日期。

如果产品规则不是“月末回退”，就不要把这个函数当成通用答案。财务结算、自然月权益和固定 30 天套餐是三个不同模型，应该在接口命名和数据字段中明确区分。

相关问题

DateInterval('P1M') 是不是固定 30 天？

不是。它代表一个日历月，结果会受到起始日和目标月份天数影响。

为什么不直接用 strtotime('+1 month')？

可以用于简单脚本，但正式业务更适合不可变对象和显式月末策略，便于统一时区、记录边界并测试。

invert 等于到期了吗？

不等于。它只是差值方向；到期状态应由当前时间点与到期时间点的比较决定。

总结

PHP 日期计算的难点不在创建一个 DateInterval，而在于把日历月、月末策略、方向表达和时间点比较拆成可验证的边界。用 DateTimeImmutable 保留输入，用目标月份天数处理溢出，再用统一时区比较结果，订阅续期和退款撤销的日期偏移才有清晰的修复路径。