microtime() 返回值类型取决于参数：不传或传 false 时返回字符串，传 true 时返回浮点数；直接用 microtime() 做减法易因字符串拼接出错，应统一用 microtime(true) 计算耗时。
microtime() 返回值到底是字符串还是浮点数？
取决于是否传 true：不传或传 false，返回形如 "0.12345678 1712345678" 的字符串；传 true 才返回浮点数（单位秒，含微秒精度）。很多同学直接用 microtime() 做减法，结果得到字符串拼接而非数值差——这是最常踩的类型坑。
实操建议：
- 要计算耗时，必须统一用
microtime(true)开始和结束，再相减 - 别用
list($usec, $sec) = explode(' ', microtime())手动拆——PHP 7.4+ 已支持microtime(false)配合sscanf，但没必要，true更直白 - 注意浮点精度：PHP 默认
float是双精度，毫秒级差值误差在 1e-15 秒量级，对业务完全够用，不用上GMP或BCMath
为什么 microtime(true) 在 CLI 和 FPM 下表现一致？
因为 microtime() 底层调用的是系统 gettimeofday()（Linux/macOS）或 QueryPerformanceCounter()（Windows），与 SAPI 无关。但要注意：CLI 脚本生命周期短，FPM 请求可能被 opcache 缓存、或受 fastcgi_finish_request() 干扰——不是 microtime 本身问题，而是你测的位置错了。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 在
fastcgi_finish_request()后调用microtime(true)，误以为是“响应耗时”，其实只是脚本剩余执行时间 - FPM 下开启
opcache.enable_cli=1测 CLI 性能，结果比实际高——opcode 缓存让初始化变快，但掩盖了真实 autoload 开销 - 用
$_SERVER['REQUEST_TIME_FLOAT']当起点，它只精确到秒级（PHP 5.4+ 才有小数），比microtime(true)开始晚几十微秒，不适合亚毫秒级测量
替代方案：hrtime() 比 microtime() 更准吗？
是的，hrtime()（PHP 7.3+）返回纳秒级整数数组，不受系统时钟调整影响（microtime 可能因 NTP 校正跳变），且无浮点舍入误差。但它不是万能的——仅适合短时高精度测量，比如函数级 benchmark，不适合记录日志时间戳（因为不能直接转成可读日期）。
使用场景对比：
- 测单个函数执行：优先用
hrtime(true)，返回int纳秒值，做减法零误差 - 记录请求开始/结束时间并存库：仍用
microtime(true)，方便转date('Y-m-d H:i:s.u') - 跨进程或分布式追踪：别依赖本地时钟，用
Trace-ID + span timestamp配合外部时间源（如 NTP 同步后的clock_gettime(CLOCK_REALTIME)）
Windows 下 microtime() 为什么有时卡住 15ms？
老版本 Windows（Win7/2008 及之前）默认系统定时器精度只有 15.625ms，microtime() 会受此限制，连续调用可能返回相同值。PHP 自身无法绕过，得靠系统级调整。
解决办法很直接：
- 升级到 Windows 10/2016+，默认精度已提升至 1–2ms
- 若必须用旧系统，运行命令
powercfg /energy检查是否启用高性能电源计划（平衡/节能模式会锁低精度） - 终极手段：用
timeBeginPeriod(1)（需winmm.dll），但 PHP 不内置封装，得写扩展或调用exec()——不推荐，副作用大
真正容易被忽略的是：这个精度问题只影响「连续高频采样」，比如循环里每轮都 microtime(true)，而 Web 请求这种单次测量基本感知不到。别一看到 Windows 就慌，先看你的用法是不是真踩中了那个 15ms 坑。
