strtotime() 返回值本身就是整型（成功时为 int，失败时为 false），无需 intval() 转换；否则会掩盖错误、触发警告、增加开销且导致语义错误。
直接用 strtotime() 就够了，不需要再套 intval()。
为什么 strtotime() 返回值本身就是整型
strtotime() 的返回值是 Unix 时间戳（秒数），PHP 内部类型为 int。在绝大多数 PHP 版本（5.1+，包括所有 7.x 和 8.x）中，它要么返回一个整数，要么失败时返回 false（不是 0 或字符串）。
- 成功时：返回类似
1717023600这样的整数 - 失败时：返回布尔值
false，不是0—— 所以不能用== 0判断错误 -
intval(false)会变成0，反而掩盖了错误，导致逻辑出 bug
常见误用：intval(strtotime($str))
这个写法不仅多余，还引入隐式类型转换风险：
- 当
$str无法解析（如"2024-09-xx"），strtotime()返回false，intval(false)得到0，而0是一个合法时间戳（1970-01-01 00:00:00 UTC），但语义完全错误 - PHP 8.1+ 开启严格模式后，
intval()对false会触发E_DEPRECATED警告 - 多一次函数调用，无谓增加开销（虽小，但无意义）
正确写法与错误处理
应该显式判断返回值是否为 false，而不是依赖类型转换：
立即学习“PHP免费学习笔记（深入）”；
$ts = strtotime($dateString);
if ($ts === false) {
throw new InvalidArgumentException("Invalid date string: '$dateString'");
}
// 此时 $ts 就是 int，可直接使用
echo $ts + 86400; // 比如加一天
- 注意用
=== false，不是== false（避免0被误判） - 如果输入来自用户或不可信源，必须做这层判断；仅对已知格式的内部数据才可省略
- 想兼容毫秒级需求？
strtotime()不支持毫秒，得用DateTime::createFromFormat()或正则预处理
替代方案：什么时候不该用 strtotime()
当日期格式固定且高频调用时，strtotime() 的字符串解析开销明显高于直接构造：
- 比如处理大量
"Y-m-d H:i:s"格式日志时间，用DateTime::createFromFormat('Y-m-d H:i:s', $s)更快、更可控 - PHP 8.2+ 支持
date_parse_from_format()，返回数组，适合需提取年月日分秒的场景 - 纯数字时间戳字符串（如
"1717023600"）—— 直接(int)$s或filter_var($s, FILTER_VALIDATE_INT)，别走strtotime()
真正容易被忽略的是：strtotime() 的容错性太强，会把很多奇怪字符串（如 "next Monday"、"+2 weekdays"）转成时间戳，而你可能只想要严格格式校验。这时候它不是“高效”，而是“危险”。
