strtotime() 不够用，因其对非法日期静默处理、格式歧义、时区不明确；parseDate() 通过显式时区、多格式尝试、错误校验解决这些问题。
为什么 strtotime() 不够用
直接用 strtotime() 解析用户输入的日期字符串，看似简单，但实际会踩一堆坑：比如 "2023-02-30" 返回 false 却不报错；"13/05/2023" 在某些 locale 下被当成 13 月而返回 false；更隐蔽的是时区问题——strtotime("2023-01-01") 默认按当前服务器时区解析，可能和前端传来的 UTC 时间对不上。
封装一个带校验和时区控制的 parseDate()
核心是三件事：统一输入格式预期、强制指定时区、明确失败反馈。不依赖 date_default_timezone_set() 全局设置，每次调用都显式传参。
- 接受字符串、
DateTimeInterface或NULL，返回DateTimeImmutable（避免意外修改）或null - 默认时区设为
"UTC"，业务需要本地时间再显式传"Asia/Shanghai" - 用
DateTime::createFromformat()替代strtotime()，能精确控制格式匹配，且getLastErrors()可查错
function parseDate($input, string $timezone = 'UTC', string $format = null): ?DateTimeImmutable { if ($input instanceof DateTimeInterface) { return new DateTimeImmutable($input->format('Y-m-d H:i:s'), new DateTimeZone($timezone)); } if (!is_string($input) || trim($input) === '') { return null; } // 若未指定 format，尝试常见格式（顺序很重要） $formats = $format ? [$format] : [ 'Y-m-dTH:i:s.uP', 'Y-m-dTH:i:sP', 'Y-m-dTH:i:s', 'Y-m-d H:i:s.u', 'Y-m-d H:i:s', 'Y-m-d H:i', 'Y-m-d', 'm/d/Y', 'd/m/Y', 'Y/m/d' ]; foreach ($formats as $fmt) { $dt = DateTime::createFromFormat($fmt, trim($input), new DateTimeZone($timezone)); if ($dt && $dt->format($fmt) === trim($input)) { // 校验是否真解析成功（防 2023-02-30 这类非法日期被静默转成 2023-03-02） $errors = DateTime::getLastErrors(); if ($errors['warning_count'] === 0 && $errors['error_count'] === 0) { return $dt->setTimezone(new DateTimeZone($timezone)); } } } return null; }调用时注意这三点
封装好函数只是第一步，用错参数照样白搭。
- 前端传
"2023-05-15T08:30:00Z"？必须显式传$format = 'Y-m-dth:i:sP'，否则可能被误判为本地时区 - 数据库字段是
DATETIME且存的是无时区时间（如"2023-05-15 08:30:00"），应传$timezone = 'Asia/Shanghai'，而非留默认'UTC' - 返回
null时别直接format()，先判断——这是最常漏掉的空指针点
和 carbon 的区别在哪
Carbon 确实更强大，但如果你项目没引入它，或只在少数地方需要轻量解析，没必要为一行代码加个包。这个函数不依赖外部库，体积小，逻辑透明，错误路径清晰。真正复杂的需求（如相对时间、多语言解析、自然语言支持）才该切到 Carbon。
立即学习“PHP免费学习笔记（深入）”；
关键是：别把“通用”等同于“大而全”。能精准覆盖你系统里 POST 表单、csv 导入、API 参数这三类主要输入源，就达到了复用目标。其余边缘 case，宁可单独写分支处理，也别让主逻辑变重。