strtotime('+1 month')遇月末会跳月，如'2024-01-31'变'2024-03-02'；安全做法是DateTime::modify('+1 month')后检查日数是否变化，若变化则设为当月最后一天。
PHP用strtotime()加一个月容易出错
直接写 strtotime('+1 month') 看似简单，但遇到月末日期会跳月——比如 '2024-01-31' 加一个月变成 '2024-03-02'（跳过了2月），不是你想要的“2024-02-29”或“2024-02-28”。这是因为 strtotime() 是按“日历天数”粗暴推进，不校验目标月份是否存在该日。
常见错误现象：date('Y-m-d', strtotime('2024-01-31 +1 month')) → '2024-03-02'；'2023-01-31 +1 month' → '2023-03-03'。
- 只在非月末日期下才“看起来正常”，一到1月31日、3月31日、5月31日等就失效
- PHP 8.2+ 的
DateTime::add()同样存在此问题，它底层也依赖类似逻辑 - 真正安全的做法是：先加月，再把日期“回拨”到当月最后一天（如果溢出）
推荐用DateTime配合modify()手动对齐
核心思路是：加完月后，检查生成的日期是否“超出”目标月的天数，如果是，就设为当月最后一天。这比硬算天数或依赖时区更可靠。
function addOneMonth($dateString) {
$dt = new DateTime($dateString);
$originalDay = (int)$dt->format('d');
$dt->modify('+1 month');
// 如果当前日 > 目标月最大日，则设为最后一天
if ((int)$dt->format('d') !== $originalDay) {
$dt->modify('last day of this month');
}
return $dt->format('Y-m-d');
}
使用示例：
立即学习“PHP免费学习笔记（深入）”；
-
addOneMonth('2024-01-31')→'2024-02-29'（闰年） -
addOneMonth('2023-01-31')→'2023-02-28' -
addOneMonth('2024-04-15')→'2024-05-15'（正常推进）
注意DateTimeZone和setTimestamp()的干扰
如果你在代码中显式设置了时区（如 $dt->setTimezone(new DateTimeZone('Asia/Shanghai'))），或用 setTimestamp() 覆盖过时间戳，modify() 行为可能受夏令时切换影响——尤其在3月/10月边界。这不是加月逻辑本身的问题，而是时区转换引发的秒级偏移，导致日期“意外跳变”。
- 确保所有操作前统一时区：
date_default_timezone_set('Asia/Shanghai')或构造时指定 - 避免混用
setTimestamp()和modify()；一旦用了setTimestamp()，后续modify()就基于那个秒数重新解析，可能丢失原始日期语义 - 测试边界值：2023-10-27（欧洲夏令时结束日）、2024-03-31（欧洲夏令时开始日）
别用date_create_from_format()绕开问题
有人想用 date_create_from_format('Y-m', '2024-01') 先取年月，再拼字符串加日，看似可控，但实际引入新坑：没处理2月29日、平年闰年、跨年进位等细节，反而更难维护。
- 这种“字符串拼接法”无法自动识别
'2024-01-31'应该落到'2024-02-29'还是'2024-02-28' - 若输入含时间（如
'2024-01-31 23:59:59'），还要额外保留时分秒，逻辑迅速膨胀 - 已有成熟方案（上文
modify()+last day of）足够简洁，没必要另起炉灶
最麻烦的地方往往不在“怎么加”，而在“加完要不要截断到月末”——这个判断必须做，且得在 modify 之后立刻做，晚一步就可能被后续操作覆盖。
