strtotime()易出错，应优先用DateTime::createFromFormat()处理固定格式，mktime()适合构造时间戳，新项目推荐DateTimeImmutable以保障类型安全与时区明确。
strtotime() 是最常用但容易出错的函数
PHP里把日期字符串转成UNIX时间戳，strtotime() 是默认选择，但它对输入格式极其敏感——不是所有“看起来像日期”的字符串都能被正确解析。
常见错误现象：strtotime("2023-02-30") 不报错，返回 false（实际是 -1 在 32 位系统），但没提示；strtotime("01/13/2023") 在美国 locale 下是 1 月 13 日，在欧洲 locale 下可能被当成非法日期。
- 优先用明确格式：比如
"Y-m-d H:i:s"，避免依赖隐式推断 - 务必检查返回值：
$ts = strtotime($date); if ($ts === false) { /* 处理失败 */ } - 时区影响真实结果：
strtotime()默认用date_default_timezone_get()设置的时区，不是 UTC —— 如果你传的是 UTC 时间字符串，得先设时区或用DateTime显式指定
DateTime::createFromFormat() 更可控，适合固定格式解析
当你确定输入日期格式（比如总是 "d/m/Y" 或 "Y.m.d"），DateTime::createFromFormat() 比 strtotime() 更可靠，它不猜格式，只按你写的模板硬匹配。
使用场景：表单提交的日期、日志文件中的时间字段、API 返回的定制化时间字符串。
立即学习“PHP免费学习笔记（深入）”；
- 必须显式传入格式字符串，例如：
DateTime::createFromFormat("d/m/Y", "25/12/2023") - 失败时返回
false，且可通过DateTime::getLastErrors()查具体哪部分不匹配 - 注意年份占位符：
y是两位年份（会自动补 20xx），Y是四位，混用会导致 19xx/20xx 错乱 - 不自动处理时区偏移，如果字符串带
+0800，格式里得写"Y-m-d H:i:s O"，否则忽略或解析失败
time() 和 mktime() 适用于构造当前或已知组件的时间戳
如果你不是解析字符串，而是拼一个时间戳（比如“今天凌晨 0 点”、“下个月第一天”），mktime() 比 strtotime() 更直接、更少歧义。
性能上，mktime() 是纯数值计算，比字符串解析快一个数量级；兼容性上，它在 PHP 8.0+ 仍完全可用，别信“已被废弃”的过时说法。
-
mktime(0, 0, 0, 12, 25, 2023)表示 2023 年 12 月 25 日 00:00:00（本地时区） - 月份和日期允许越界：比如
mktime(0,0,0,13,1,2023)自动变成 2024 年 1 月 1 日 - 不接受字符串参数，所有值都必须是整数；传字符串如
"12"会被强制转换，但"12a"变成 0，易埋坑 - 若需 UTC 时间戳，别用
gmmktime()（已废弃），改用DateTime+setTimezone(new DateTimeZone('UTC'))
PHP 8.2+ 推荐用 DateTimeImmutable + getTimestamp() 做类型安全转换
新项目或需要长期维护的代码，DateTimeImmutable 是更现代、更不易出错的选择。它强制不可变，避免意外修改原始对象，getTimestamp() 返回整型时间戳，类型明确。
容易被忽略的一点：DateTime 构造时若字符串含时区信息（如 "2023-01-01T12:00:00+08:00"），它会自动按该时区解释；而 strtotime() 可能忽略或误判。
- 基础用法：
(new DateTimeImmutable("2023-04-05"))->getTimestamp() - 带时区更稳妥：
(new DateTimeImmutable("2023-04-05", new DateTimeZone("Asia/Shanghai")))->getTimestamp() - 解析失败抛
Exception，不是返回false，必须 try/catch —— 这反而是好事，逼你处理异常路径 - 不要省略时区参数：没传时区时，它用
date_default_timezone_get()，但这个值可能在运行中被其他代码改掉
真正麻烦的从来不是“怎么转”，而是“谁负责保证输入格式稳定”和“时区上下文是否清晰”。字符串来源不可控时，strtotime() 容错假象最多；固定格式且要精确控制时，createFromFormat() 才是解药；至于新项目，直接上 DateTimeImmutable，少踩五年后的坑。
