17370845950

date() 和 strtotime() 是 PHP 性能瓶颈，因重复解析、时区转换和格式编译开销大；应优先用 DateTimeImmutable::createFromFormat()、复用实例、直接操作时间戳，并确保 intl 扩展启用。

date() 和 strtotime() 是性能瓶颈源头

PHP 中 date() 和 strtotime() 在循环里频繁调用时明显拖慢脚本，尤其当输入是字符串且含时区、模糊格式（如 "last Monday"）时，解析开销陡增。它们不是纯计算函数，内部要走完整的日期解析器 + 时区查表 + 格式化引擎。

• strtotime("2025-10-05 14:30:00") 比直接用 mktime() 慢 3–5 倍
• 每次调用 date("Y-m-d H:i:s", $ts) 都重新编译格式字符串，无缓存
• 若已知时间戳为 UTC，却未设 date_default_timezone_set("UTC")，PHP 会隐式做时区转换，额外耗时

优先用 DateTimeImmutable + 预编译格式

用 DateTimeImmutable 替代 date()/strtotime() 组合，尤其在批量处理时。关键点是复用 DateTimeImmutable::createFromFormat() 和避免重复 new。

• 对固定格式字符串（如 "Y-m-d H:i:s"），用 createFromFormat() 比 strtotime() 快 2–4 倍，且可禁用相对时间解析（加第 3 个参数 false）
• 格式字符串应硬编码，不要拼接；DateTime::ATOM 等常量比写死字符串更安全且略快
• 若只需输出，且格式固定，可提前创建 DateTimeZone 实例并复用，避免每次 new

$tz = new DateTimeZone('Asia/Shanghai');
$dt = DateTimeImmutable::createFromFormat('Y-m-d H:i:s', '2025-10-05 14:30:00', $tz);
if ($dt === false) { /* 处理解析失败 */ }
echo $dt->format('Y-m-d'); // 复用同一实例多次 format

时间戳能用就别转字符串

很多场景其实不需要“转成日期”，而是做比较、加减、分组——这些全可用整数时间戳完成，零解析成本。

• 数据库查询中用 WHERE created_at >= 1700000000，而非 WHERE DATE(created_at) = '2025-11-15'
• 按天分组？用 floor($ts / 86400) * 86400 得到当天零点时间戳，比 date("Y-m-d", $ts) 后再 strtotime() 回来快一个数量级
• 缓存层（如 Redis）存时间戳而非格式化后字符串，节省序列化/反序列化和内存

注意 intl 扩展未启用时的隐式降级

当代码含 IntlDateFormatter 或依赖 datefmt_* 函数时，若服务器没开 intl 扩展，PHP 会 fallback 到慢速 C locale 实现，且不报错——你只看到变慢，却找不到原因。

• 上线前检查 extension_loaded('intl')，未加载则明确 fail fast 或降级到简单 date()
• datefmt_format() 在启用了 intl 时支持缓存格式器实例，但未启用时每次调用都重建，性能差 10 倍以上
• Docker 镜像或共享主机常默认不装 intl，这点容易被忽略

实际压测中，把千条日志的日期解析从 foreach ($logs as $log) { date('Y-m', strtotime($log['time'])); } 改为预解析 + 时间戳运算，耗时从 85ms 降到 9ms。真正卡住的往往不是算法，而是没意识到字符串解析这一步根本可以绕开。