microtime()函数提供微秒级时间精度，返回浮点数形式的时间戳，适用于性能测试、高精度计时和生成唯一ID；相比秒级精度的time()函数，microtime(true)能更精确测量代码执行时间，尤其适合需要细粒度时间记录的场景。
PHP的
microtime()函数是一个获取当前Unix时间戳的利器，但它比我们常用的
time()函数更精确，能提供微秒级别的时间信息。简单来说，它能让你知道当前时间精确到小数点后六位，对于需要高精度时间戳的场景，比如性能测试或者生成更独特的ID，它就是不二之选。
解决方案
microtime()函数的基本用法其实非常直观，它有两种调用方式，取决于你想要什么格式的输出。
默认情况下，也就是不传入任何参数时，
microtime()会返回一个字符串，格式是"微秒数 秒数"。比如，你可能会看到类似
"0.123456 1678901234"这样的结果，其中
0.123456是当前秒内的微秒部分，
1678901234是Unix时间戳（从1970年1月1日00:00:00 GMT到现在的秒数）。
$default_output = microtime(); echo "默认输出: " . $default_output . PHP_EOL; // 示例输出: 默认输出: 0.12345600 1678901234
这种字符串格式在某些场景下需要我们手动解析，有点麻烦。所以，更多时候，我们会传入一个
true作为参数，让
microtime()直接返回一个浮点数。这个浮点数就是包含了微秒部分的Unix时间戳，方便直接进行数学运算。
立即学习“PHP免费学习笔记（深入）”；
$float_output = microtime(true); echo "浮点数输出: " . $float_output . PHP_EOL; // 示例输出: 浮点数输出: 1678901234.123456
在我看来，这种浮点数形式是
microtime()最常用也最实用的输出方式。它把秒数和微秒数合并成一个单一的数值，极大地简化了时间计算，特别是用于测量代码执行时间时，直接相减就能得到结果。
PHP microtime()
函数与time()
函数有何不同？何时选择使用它？
说实话，这个问题经常有人问。
microtime()和
time()最核心的区别就在于精度。
time()函数返回的是一个整数，表示从Unix纪元（1970年1月1日00:00:00 GMT）到当前时间的秒数。它的精度是秒，也就是说，如果你在同一秒内多次调用
time()，它返回的值都是一样的。
$t1 = time(); usleep(100000); // 暂停100毫秒 $t2 = time(); echo "time()结果: " . $t1 . " 和 " . $t2 . PHP_EOL; // 如果在同一秒内，可能 $t1 == $t2
而
microtime()，正如其名，提供了微秒级别的精度。它返回的浮点数包含了秒数和当前秒内的微秒数。这意味着，即使在同一秒内，只要有微小的间隔，
microtime(true)返回的值也会不同。
那么，何时选择
microtime()呢？
-
性能基准测试（Benchmarking）：这是
microtime()
最经典的用途。当你需要精确测量一段代码、一个函数或者整个脚本的执行时间时，time()
的秒级精度显然不够用。microtime()
能让你看到毫秒甚至微秒级别的差异，这对于优化性能至关重要。 -
生成更独特的ID：虽然不是
microtime()
的直接功能，但它常常与uniqid()
函数结合使用，生成更不容易重复的唯一ID。uniqid()
默认就是基于当前微秒时间戳生成的，精度越高，重复的可能性就越小。 - 需要高精度时间记录：比如记录某些事件的发生时间，需要比秒更细粒度的信息，以便后续分析事件发生的精确顺序或间隔。
简单来说，如果你只需要知道“大概是几点几分几秒”，
time()就足够了。但如果你想知道“具体花了多少毫秒”或者“这个事件发生在那个事件的多少微秒之后”，那
microtime()就是你的首选。
如何利用microtime()
精确测量PHP脚本的执行时间？
测量脚本执行时间是
microtime(true)最常见的应用场景，也是它真正发挥价值的地方。整个过程其实很简单，核心思路就是“开始时间点”减去“结束时间点”。
我们通常会在要测量的那段代码执行之前，记录一个开始时间戳。然后，在代码执行完毕之后，再记录一个结束时间戳。最后，用结束时间减去开始时间，得到的就是这段代码的执行耗时。
// 记录脚本开始执行的时间点
$start_time = microtime(true);
// 这里是你要测量性能的代码块
// 比如，一个耗时操作，或者一个复杂的数据库查询
for ($i = 0; $i < 1000000; $i++) {
// 模拟一些计算
$result = sqrt($i);
}
// 记录脚本结束执行的时间点
$end_time = microtime(true);
// 计算执行耗时
$execution_time = $end_time - $start_time;
echo "代码块执行耗时: " . sprintf('%.6f', $execution_time) . " 秒" . PHP_EOL;
// 示例输出: 代码块执行耗时: 0.008765 秒 (具体数值取决于机器性能和循环次数)这个方法看似简单，但实际操作中，有几个小点值得我们留意。首先，
microtime(true)返回的是浮点数，直接进行减法运算很方便。其次，使用
sprintf('%.6f', $execution_time)可以把结果格式化成小数点后六位，让显示更清晰。
当然，这种测量方式测量的是PHP脚本在服务器上的执行时间。它会受到服务器负载、I/O操作（比如文件读写、数据库查询）、网络延迟等多种因素的影响。所以，如果你想进行严谨的性能测试，建议多次运行取平均值，并且尽量在稳定的、隔离的环境下进行。它提供的是一个内部参考，而不是用户实际感受到的页面加载时间，因为用户感受到的时间还包括了网络传输、前端渲染等因素。
在并发或高负载环境下，microtime()
函数有哪些需要注意的细节？
在高并发或高负载的环境下使用
microtime()，虽然它本身是一个非常可靠的函数，但结合整个系统来看，确实有一些细节值得我们思考。
一个常见的场景是，
microtime()的精度被用来生成唯一标识符（UUID/GUID）。PHP的
uniqid()函数就利用了
microtime()。理论上，微秒级的时间戳加上一个随机前缀，生成唯一ID的冲突概率已经非常低了。但话说回来，在极端高并发，比如同一微秒内有数万甚至数十万个请求同时到达，并且都在尝试生成ID时，理论上仍然存在极小的碰撞可能。这通常不是
microtime()本身的问题，而是整个ID生成策略需要考虑分布式锁或更复杂的ID生成算法（如Snowflake算法）来确保绝对唯一性。对于大多数Web应用来说，
uniqid('', true)（增加熵）结合microtime()的精度已经足够了。
另一个需要注意的点是系统时钟漂移。
microtime()依赖于服务器的系统时钟。如果服务器配置了NTP（网络时间协议）服务来同步时间，那么在时钟调整时，可能会出现“时间倒流”的情况，即一次
microtime()调用返回的时间戳比前一次更小。这种情况不常见，但对于那些对时间单调性有严格要求的系统（比如金融交易系统或日志记录系统），这可能是一个严重的bug。解决办法通常是使用专门的单调时钟API（如果操作系统提供的话），或者在应用层进行额外的检查和补偿。PHP本身并没有直接提供一个跨平台的单调时钟函数，所以这是需要系统层面考虑的问题。
最后，虽然
microtime()的调用开销非常小，几乎可以忽略不计，但在一些极其性能敏感的紧密循环中，反复调用任何函数都会累积微小的开销。不过，对于绝大多数PHP应用来说，这种开销根本不会成为瓶颈。我们更应该关注的是代码逻辑、数据库查询、I/O操作等真正耗时的部分。所以，没必要过度担忧
microtime()自身的性能影响。它的价值在于提供精确的时间点，而不是它本身有多“快”。
