php原生strtotime()不支持毫秒解析，需用datetime::createfromformat()配合"y-m-d h:i:s.u"格式及6位微秒补零处理，再组合秒戳与微秒计算毫秒级时间戳。
PHP strtotime() 不支持毫秒字符串
直接用 strtotime("2024-01-01 12:00:00.123") 会截断毫秒部分，返回的 int 时间戳精度只有秒。PHP 原生 strtotime() 和 DateTime::__construct()（无额外处理）均不解析小数秒——它把 .123 当作非法字符忽略，或触发警告但继续解析为整秒时间。
用 DateTime::createFromFormat() 显式解析毫秒
这是最可控的方式：你必须明确告诉 PHP 哪里是毫秒位，并用 u 格式符接收微秒（注意：u 是微秒，不是毫秒；1 毫秒 = 1000 微秒，所以字符串中毫秒需补零成 6 位）。
- 输入字符串含毫秒（如
"2024-05-20 14:30:45.890"），需先补零为"2024-05-20 14:30:45.890000" - 格式串写成
"Y-m-d H:i:s.u"，其中u匹配 6 位微秒 - 解析后可用
$dt->format('U.u')获取带微秒的时间戳字符串，或(float)sprintf('%.6F', $dt->getTimestamp() + $dt->format('u') / 1000000)得浮点毫秒级时间戳
date_default_timezone_set('UTC');
$ms_str = "2024-05-20 14:30:45.890";
// 补零到6位微秒
$us_str = preg_replace('/\.(\d{1,3})$/', '.${1}000000', $ms_str);
$us_str = substr($us_str, 0, -6) . str_pad(substr($us_str, -6), 6, '0', STR_PAD_RIGHT);
<p>$dt = DateTime::createFromFormat('Y-m-d H:i:s.u', $us_str);
if (!$dt || $dt->getLastErrors()['warning_count'] > 0) {
throw new InvalidArgumentException('Invalid datetime string with ms');
}</p><p>$timestamp_ms = (int)($dt->getTimestamp() * 1000) + (int)($dt->format('u') / 1000);
// → 1716215445890注意 DateTimeZone 和时区偏移对毫秒的影响
毫秒值本身与时区无关，但解析行为受默认时区影响。若字符串含时区信息（如 "2024-05-20T14:30:45.890+08:00"），createFromFormat() 无法直接处理带偏移的毫秒格式——它不支持 O 或 P 与 u 混用。此时应改用 new DateTime($str)，但它仍会丢弃毫秒。
- 安全做法：先用正则提取毫秒和时区两部分，分别处理
- 或统一转为 UTC 字符串再解析（例如将
+08:00换算后生成无偏移 + 毫秒补零的 UTC 字符串） -
date_default_timezone_set()只影响无时区标注的字符串，默认设为UTC可避免隐式转换偏差
性能与兼容性提醒
频繁做毫秒解析时，DateTime::createFromFormat() 比 new DateTime() 稍慢但稳定；PHP 7.3+ 对 u 格式支持良好，但低于 7.2 的版本可能返回 false 或静默失败。
立即学习“PHP免费学习笔记（深入）”；
- 别依赖
microtime(true)反向构造字符串再解析——浮点精度会导致毫秒错位 - MySQL 的
DATETIME(3)输出格式是"Y-m-d H:i:s.u"（3 位），但 PHP 要求u必须是 6 位，务必补零 - JSON 中传毫秒时间建议直接用整数时间戳（毫秒级），而非字符串，规避解析歧义
毫秒解析真正麻烦的从来不是“怎么写”，而是“哪来的毫秒、带不带时区、有没有截断、补零逻辑对不对”——这些细节漏一个，结果就差好几秒。
