最可靠方式是用 DateTime 对象比较日期时间，因其封装解析、时区和计算，避免字符串或时间戳比较的时区、格式歧义等问题。
PHP 用 DateTime 对象比较日期时间最可靠
直接用字符串或时间戳比较容易出错，比如时区不一致、格式歧义（"2023-01-02" 和 "02/01/2023" 解析结果不同）。DateTime 把解析、时区、计算全封装好了，是 PHP 官方推荐的唯一健壮方式。
常见错误现象：用 strtotime() 转成整数再比大小，结果在夏令时切换日、跨时区场景下翻车；或者用 date("Y-m-d") == date("Y-m-d") 忽略了时间部分。
- 初始化必须显式指定时区，否则默认用
date_default_timezone_get()，线上环境可能和本地不一致 - 比较操作符（
<、>、==）可直接用于DateTime对象，底层调用的是getTimestamp()，但更安全 - 若需忽略时间只比日期，用
$dt->format("Y-m-d")再比较，别用setTime(0,0,0)后比——后者仍受时区偏移影响
用 diff() 算两个时间差时注意返回值含义
DateTime::diff() 返回 DateInterval 对象，它不表示“从 A 到 B 经过了多久”，而是“B 减 A 的绝对差值”。符号信息藏在 $interval->invert 里，不是靠 $interval->days 正负判断。
典型误用：写 if ($a->diff($b)->days > 0) 想判断 $b 是否晚于 $a——这完全不可靠，因为 days 永远非负。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法：先用
$a < $b判断顺序，再调用diff()计算间隔 -
$interval->days是总天数（不含年月），$interval->d是“日”字段（比如 1 年 2 月 3 天里的 3），二者常被混淆 - 跨月计算时，
diff()默认按日历月对齐（如 1 月 31 日到 2 月 28 日算 28 天，不是 28 天零几小时），有精度损失
strtotime() 在简单场景下能用，但必须加校验
如果只是处理用户输入的 "today"、"+3 days" 这类固定表达式，strtotime() 速度快、写法短。但它不抛异常，解析失败时静默返回 false，极易埋雷。
错误现象：用户输错格式（如 "2023/13/01"），strtotime() 返回 false，转成整数是 0，变成 1970-01-01，后续比较全乱套。
- 每次调用后必须检查返回值：
$ts = strtotime($input); if ($ts === false) { /* 处理错误 */ } - 避免依赖隐式时区，显式拼上时区字符串：
strtotime("now Asia/Shanghai") - 不要用它解析带毫秒的 ISO 8601 字符串（如
"2023-01-01T12:00:00.123Z"），DateTime才支持
MySQL 时间字段和 PHP DateTime 交互的坑
PHP 读取 MySQL 的 DATETIME 或 TIMESTAMP 字段时，PDO 默认返回字符串（如 "2023-05-20 14:30:00"），不是 DateTime 对象。直接拿字符串比较会退化为字典序，比如 "2023-01-10 00:00:00" > "2023-01-02 23:59:59" 成立，但 "2023-01-02 10:00:00" > "2023-01-02 09:00:00" 就不一定——取决于字符串长度和填充。
- PDO 预设
PDO::ATTR_EMULATE_PREPARES = false且 MySQLi 启用MYSQLI_OPT_INT_AND_FLOAT_NATIVE也**不**影响时间字段类型，必须手动转换 - 稳妥写法：
$dt = new DateTime($row["created_at"]);，并确保构造时传入数据库所在时区（如new DateTime($row["created_at"], new DateTimeZone("Asia/Shanghai"))） - 写入前务必用
$dt->format("Y-m-d H:i:s")格式化，别直接插$dt->__toString()——后者可能带毫秒或时区偏移，MySQL 会截断或报错
时区不是可选项，是必填项；字符串比较永远不如对象比较可靠；所有外部输入的时间值，第一步不是解析，是验证是否解析成功。
