DateTime 不报错而自动修正非法日期是设计行为，优先生成有效日期对象；需用 createFromFormat() 校验输入与输出是否一致来检测闰年错误。
PHP 字符串转日期本身不关心闰年，但闰年会影响转换结果的正确性——尤其是当原始字符串包含 2月29日 且目标年份不是闰年时，DateTime 会静默调整日期（比如变成 3月1日），而不是报错。
为什么 DateTime 不报错而是自动修正？
PHP 的 DateTime 构造器和 strtotime() 都基于系统级日期解析逻辑，对无效日期采取“归一化”策略。这不是 bug，是设计行为：它优先保证能生成一个有效日期对象，而非中断执行。
-
"2023-02-29"→ 解析为2023-03-01（2023 年不是闰年） -
"2024-02-30"→ 解析为2024-03-01（2月最多29天） -
"2024-02-29"→ 正确保留（2024 是闰年）
如何检测字符串是否含非法闰年日期？
不能依赖 DateTime::getLastErrors()，它对这类“可归一化”的日期不报错。必须手动校验原始字符串与解析后日期是否一致：
function isValidDateStr($dateStr) {
$dt = DateTime::createFromFormat('Y-m-d', $dateStr);
if (!$dt) return false;
// 比较格式化后的输出是否和输入完全一致
return $dt->format('Y-m-d') === $dateStr;
}
var_dump(isValidDateStr('2023-02-29')); // false
var_dump(isValidDateStr('2024-02-29')); // true
注意：createFromFormat() 第二个参数必须严格匹配格式，否则返回 false；用 strtotime() 或无格式构造则无法做此判断。
立即学习“PHP免费学习笔记（深入）”；
使用 DateTimeImmutable 有区别吗？
没有。闰年处理逻辑与 DateTime 完全相同，区别仅在于不可变性。如果你在批量处理用户输入的日期字符串（如表单提交），建议统一用 DateTimeImmutable 避免意外修改，但校验逻辑不变。
- 闰年判断本身由 PHP 内部根据格里高利历规则完成，无需手动实现
isLeapYear() - 跨年计算（如
modify('+1 year')）会自动考虑闰年：从2024-02-29加一年得2025-03-01，不是2025-02-29
真正容易被忽略的是：前端传来的 "2023-02-29" 可能是用户手输错误、日历组件 bug 或爬虫脏数据，而 PHP 默认“帮它圆回来”，导致业务逻辑误判。校验必须在转换后立刻做，不能假设 new DateTime($str) 返回的就是你看到的那个字符串。
