PHP 时间处理避坑：date、strtotime 与 DateTime 该用哪个

**结论：只做格式化输出用 `date()`，解析一次性可控字符串可以用 `strtotime()`，但只要涉及时区、时间加减、差值计算、跨月跨年、存库落地，一律用 `DateTimeImmutable`。** 记住这条，能避开 PHP 时间处理里九成以上的坑。下面按「先立两条铁律，再逐个说坑」的顺序讲清楚。

铁律一：存库统一 UTC，展示时才转时区

时间问题本质是时区问题，不是函数问题。Unix 时间戳（从 1970-01-01 00:00:00 UTC 起的秒数）本身不带时区，`time()` 返回的值全世界一致；而 `date()`、`strtotime()` 的解析结果都会受 `date_default_timezone_set()` 影响。

所以标准做法是：数据库存 UTC 时间戳（`INT`）或 UTC 的 `DATETIME`，展示时再用用户时区转换。很多「显示时间差 8 小时」的排查到最后都是：php.ini 里没写 `date.timezone`，PHP 退到 UTC，而业务代码按北京时间理解，两边对不上。

顺便提醒：MySQL 的 `DATETIME` 不带时区语义，`TIMESTAMP` 会跟着连接时区自动转换，两者混用是排查噩梦，团队里统一一种。

铁律二：别用比较字符串的方式比较时间

`'2024-1-5' > '2024-01-04'` 这种写法在格式不统一时会给出错误答案。时间比较只认两种形式：整数时间戳，或者 `DateTimeInterface` 对象（PHP 原生支持 `<`、`>`、`==` 按时刻比较）。

date()：它只会「翻译」，不会计算

`date()` 的职责单一——把一个时间戳翻译成人类可读字符串，第二个参数默认 `time()`。它不会算时间差，也不会「加一个月」。

结论：`date()` 只适合「我手上已经有一个确定的时间戳，现在要打印出来」这一种场景。

常见错误写法是 `date('Y-m-d', strtotime('+1 month'))` 这种嵌套，一旦 `strtotime` 因输入异常返回 `false`，`date()` 会把 `false` 当 `0` 处理，直接输出 `1970-01-01`，而且不报错——这是线上最隐蔽的一类 bug。

strtotime()：快，但必须处理两个坑

第一个坑：解析失败返回 `false`。所以判断必须写全 `=== false`，不能写 `if (!$ts)`，因为合法的 `0` 也会被误判。

$ts = strtotime($input);
if ($ts === false) {
    // 输入不合法，走兜底逻辑
}

第二个坑：相对格式存在「溢出」行为。`strtotime('2024-01-31 +1 month')` 得到的是 3 月 2 日，不是 2 月 29 日——因为它是先给「月份数」加一（变成 2 月 31 日），再把不存在的日期往后溢出。正确表达「下个月的同一天」应该显式用修饰符，比如 `strtotime('first day of next month')`，或者用 `DateTimeImmutable` 再手工钳制日期。

另外，PHP 8.1 起给 `date()`、`strtotime()` 传 `null` 会触发弃用警告，Clara BBS 支持 PHP 7.4–8.5 的宽版本区间，插件代码里不要依赖隐式的 `null → 0` 转换。

DateTimeImmutable：默认就该选它

`DateTimeImmutable`（不可变日期时间对象）和 `DateTime` 的唯一区别是：前者的 `add()`、`modify()`、`setDate()` 全部返回新对象，不动原值；后者是原地修改。

结论：除非你明确需要原地修改，否则一律用 `DateTimeImmutable`，因为它从根上消灭了「对象被别处改掉」的幽灵 bug。

它的几个实用点：

• 时区显式化：`new DateTimeImmutable('2024-01-01 00:00:00', new DateTimeZone('Asia/Shanghai'))`，之后 `setTimezone()` 随便转，不用碰全局默认值。
• 差值计算：`$a->diff($b)` 返回 `DateInterval`，天数直接读 `$interval->days`，跨月跨年不用自己算。
• 格式化：`->format('Y-m-d H:i:s')`，和 `date()` 同一套格式字符，迁移成本几乎为零。

一份决策清单

• 已知时间戳 → 展示字符串：`date()`
• 解析格式固定的用户输入，且输入完全可控：`strtotime()`，但必须判 `=== false`
• 算「7 天后」「还剩几天到期」「本月第一天」：`DateTimeImmutable`
• 涉及多时区、用户自定义时区：`DateTimeImmutable`
• 要落库：先转 UTC 再存

写在 Clara BBS 插件开发场景里

Clara BBS 是无需 Composer、上传即用的轻量 PHP 论坛系统，插件放在 `content/plugins` 下走运行时钩子加载，这意味着你没法像常规项目那样 `composer require` 一个 Carbon 之类的日期库——把 `DateTimeImmutable` 用熟就是刚需。

具体到业务：Cron::register 注册的定时任务是懒触发、零配置的，而「连续签到天数」「会员到期自动失效」这类逻辑跟「自然日」强绑定，一旦服务器时区、PHP 时区、数据库时区三者不一致，就会整体差一天。稳妥做法是在插件里显式指定时区构造时间对象，不要依赖全局默认值。

收束

时间处理的答案其实很清晰：`date()` 管输出，`strtotime()` 管可控输入的快速解析（且必须判 `false`），其余一律交给 `DateTimeImmutable`，存储统一 UTC、展示时再转时区。真正让人踩坑的从来不是函数本身，而是三处时区配置不一致——那才是排查时间 bug 时应该第一个检查的地方。