date() 和 strtotime() 是 php 性能瓶颈，因重复解析、时区转换和格式编译开销大；应优先用 datetimeimmutable::createfromformat()、复用实例、直接操作时间戳，并确保 intl 扩展启用。
date() 和 strtotime() 是性能瓶颈源头
PHP 中 date() 和 strtotime() 在循环里频繁调用时明显拖慢脚本，尤其当输入是字符串且含时区、模糊格式（如 "last Monday"）时，解析开销陡增。它们不是纯计算函数，内部要走完整的日期解析器 + 时区查表 + 格式化引擎。
-
strtotime("2023-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', '2023-10-05 14:30:00', $tz);
if ($dt === false) { /* 处理解析失败 */ }
echo $dt->format('Y-m-d'); // 复用同一实例多次 format时间戳能用就别转字符串
很多场景其实不需要“转成日期”，而是做比较、加减、分组——这些全可用整数时间戳完成，零解析成本。
- 数据库查询中用
WHERE created_at >= 1700000000，而非WHERE DATE(created_at) = '2023-11-15' - 按天分组？用
floor($ts / 86400) * 86400得到当天零点时间戳，比date("Y-m-d", $ts)后再strtotime()回来快一个数量级 - 缓存层（如 Redis）存时间戳而非格式化后字符串，节省序列化/反序列化和内存
注意 intl 扩展未启用时的隐式降级
当代码含 IntlDateFormatter 或依赖 datefmt_* 函数时，若服务器没开 intl 扩展，PHP 会 fallback 到慢速 C locale 实现，且不报错——你只看到变慢，却找不到原因。
立即学习“PHP免费学习笔记（深入）”；
- 上线前检查
extension_loaded('intl')，未加载则明确 fail fast 或降级到简单date() -
datefmt_format()在启用了intl时支持缓存格式器实例，但未启用时每次调用都重建，性能差 10 倍以上 - Docker 镜像或共享主机常默认不装
intl，这点容易被忽略
实际压测中，把千条日志的日期解析从 foreach ($logs as $log) { date('Y-m', strtotime($log['time'])); } 改为预解析 + 时间戳运算，耗时从 85ms 降到 9ms。真正卡住的往往不是算法，而是没意识到字符串解析这一步根本可以绕开。
