strtotime('-1 year')在2月29日会返回次月1日，因硬减365天；推荐用datetime::modify('-1 year')自动归正为2月28日，并显式设时区、验证对象有效性。
用 strtotime() 加减一年最常用，但有陷阱
直接写 strtotime('-1 year') 看似简单，实际在 2 月 29 日这类日期会出错——比如 2024-02-29 执行后得到的是 2023-03-01，而不是你期待的 2023-02-28。原因在于 PHP 的 strtotime() 不做日期回退处理，而是按日历天数硬减 365 天，再解析成合法日期。
- 适用于非闰年 2 月以外的大部分日期，比如
2023-05-15→2022-05-15 - 遇到
2024-02-29，strtotime('-1 year')返回2023-03-01（不是错误，是设计如此） - 如果业务要求“去年同月同日”，必须手动兜底：先尝试减一年，再检查月份是否变化，变了就设为当月最后一天
更稳妥的做法：用 DateTime 类 + modify() 或 sub()
DateTime 对象在处理边界日期时比 strtotime() 更可预测，尤其配合 modify() 使用时，它会自动对无效日期做归正（例如把 2024-02-29 改为 2023-02-28）。
- 推荐写法：
$date = new DateTime('2024-02-29'); $date->modify('-1 year');→ 得到2023-02-28 -
sub(new DateInterval('P1Y'))行为类似，但注意P1Y是“一年”，不是“365 天”，仍会触发归正逻辑 - 避免用
add(new DateInterval('P-1Y'))，语义反直觉且易混淆 - 如果需严格保持“同一日历位置”（如报表对比），归正是合理行为；若需绝对天数偏移（如合同到期），才该用
sub(new DateInterval('P365D'))
跨年时注意时区和默认日期格式影响
没显式指定时区时，DateTime 会用 date_default_timezone_get() 的值，而 strtotime() 默认用系统时区。两者混用可能在夏令时切换日附近产出不同结果。
- 始终显式设置时区：
new DateTime('2024-01-01', new DateTimeZone('Asia/Shanghai')) - 输入字符串不带时区（如
'2024-02-29'）会被当作本地时间解析，不是 UTC —— 这点常被忽略 - 用
format('Y-m-d')输出前，确认对象内部时间是否符合预期，必要时用getTimestamp()检查秒数
别忘了验证返回值是否有效
PHP 不会在 DateTime 构造失败时抛异常，而是静默创建一个“假”对象（比如传入 'invalid-date'），后续调用 format() 可能返回空或错误结果。
立即学习“PHP免费学习笔记（深入）”；
- 构造后立刻检查：
if (!$date instanceof DateTime || $date->format('Y-m-d') === false) { /* 处理错误 */ } -
strtotime()失败返回false，必须判空：$ts = strtotime($input); if ($ts === false) { ... } - 用户输入或数据库读出的日期字符串，可能含空格、中文符号、多余换行，建议先
trim()再解析
日期计算看着简单，真正卡住人的往往不是语法，而是闰年、时区、归正逻辑这三块拼图怎么咬合。写完记得拿 2024-02-29 和 2023-01-01 这类边界值跑一遍。
