群里有人问 PHP 怎么拿毫秒，底下回复五花八门：有人给 microtime，有人给 date 的 u 参数，还有人贴了一个自制的 microtime_float 函数。问题往往不在函数本身，而在没分清秒、毫秒、微秒这三种单位。

单位先捋清楚

1 秒等于 1000 毫秒，1 毫秒等于 1000 微秒。PHP 原生的 microtime 精确到微秒级，time 只到秒。所谓毫秒时间戳是 13 位，微秒是 16 位，秒是 10 位，长度不一样，存数据库时字段类型也得跟着变，10 位和 13 位混着存迟早出问题。

三个高频踩坑

  • 把微秒当毫秒：某些格式化参数返回六位微秒，直接扔进毫秒字段会多三位，看着是 123 其实是 123456。
  • 浮点精度丢位：microtime(true) 是双精度浮点，整数秒已占 10 位有效数字，小数部分只剩几位，长期运行的进程里可能出现时间不再前进的怪现象。
  • 时区没设：date.timezone 空着时格式化出来差 8 小时，毫秒再准也没意义。

跨语言对接最容易被卡住

前端 Date.now() 给的是 13 位毫秒，Java 的 System.currentTimeMillis() 也是 13 位，PHP 的 time 却是 10 位。三端混用不换算，日志时间线永远对不上。约定统一用毫秒时间戳，接口文档里注明单位，比事后查半天强。

性能计时别看错单位

用 microtime(true) 前后相减做耗时统计，单位是秒，要显示成毫秒得乘 1000。很多人直接把 0.00032 当成 32 毫秒，其实那是 0.32 毫秒，差了整整一百倍。接口耗时监控建议改用 hrtime，它返回纳秒整数，不受系统时间调整影响，长时间运行的脚本更可靠。

最后一句：精度不是越高越好。日志打 13 位够用，超时判断用秒级就够，把毫秒当成标配，只会让存储和排查都变复杂。