应使用 DateTime::createFromFormat() 严格校验日期有效性，因其对非法日期（如2023-02-30）和格式错误均返回 false，并可通过 getLastErrors() 检测警告；而 strtotime() 和 new DateTime() 会自动修正错误导致误判。
用 DateTime::createFromFormat() 检测格式化日期是否有效
直接用 strtotime() 或 new DateTime() 判断容易误判——比如 "2023-02-30" 会被自动转成 "2023-03-02"，看似成功，实则原字符串根本不存在这一天。
正确做法是用 DateTime::createFromFormat() 配合严格校验：
- 指定明确格式（如
"Y-m-d H:i:s"），并传入待检测字符串 - 检查返回值是否为
false—— 格式不匹配或非法日期（如 2 月 30 日）都会返回false - 再调用
DateTime::getLastErrors()确认是否有警告（例如多出空格、年份溢出等）
示例：
$dateStr = "2023-02-30";
$dt = DateTime::createFromFormat("Y-m-d", $dateStr);
if ($dt === false || array_filter(DateTime::getLastErrors()['warnings'])) {
echo "无效日期";
} else {
echo "有效";
}
处理带时区或非标准分隔符的字符串
当输入可能是 "2023/03/15 14:30"、"15-03-2023" 或含时区如 "2023-03-15T14:30:00+08:00" 时，不能只靠一个固定格式。
立即学习“PHP免费学习笔记（深入）”；
建议策略：
- 优先尝试最可能的格式（如 ISO 8601：
"Y-m-d\TH:i:sP"），再 fallback 到常见变体 - 对模糊格式（如
d-m-Y和m-d-Y）需结合业务上下文判断，PHP 本身不自动推断 - 含时区字符串必须用
P（+08:00）或O（+0800）格式符，否则解析失败但不报错
注意：DateTime::createFromFormat() 不会自动修正时区偏移错误，"2023-03-15T14:30:00+99:99" 会静默失败为 false。
strtotime() 仅适合宽松场景，慎用于校验
strtotime() 的设计目标是“尽力解析”，不是“严格验证”。它会接受大量非法输入并做隐式转换：
-
strtotime("2023-02-30")→ 返回 3 月 2 日的时间戳 -
strtotime("30-02-2023")→ 可能解析为 2023-03-02（取决于系统 locale） -
strtotime("2023-13-01")→ 解析为 2024-01-01
所以除非你明确需要容错式转换（比如日志时间字段有脏数据），否则不要用 strtotime() 做有效性判断。它的返回值为 false 仅代表完全无法识别，不代表输入合法。
注意 PHP 版本差异与 DateTimeZone 干扰
PHP 7.3+ 对 DateTime::createFromFormat() 的错误报告更严格；而 PHP 5.6 中某些边界情况（如 0000 年）可能不触发 false 返回。
另一个易忽略点：DateTimeZone 设置会影响解析结果，尤其是夏令时切换日附近：
- 在
"Europe/London"下解析"2023-10-29 01:30:00"可能返回两个不同时间（夏令时结束当天有两遍 1:30） - 若未显式传入时区，会使用默认时区，可能导致跨环境行为不一致
建议：校验阶段统一用 UTC 时区，避免歧义；业务逻辑中再按需转换。
