用microtime(true)测耗时最可靠，必须传true参数得浮点数、起止点紧贴被测代码首尾、禁用xdebug、循环1000次取中位数，避免i/o干扰和系统调度偏差。
microtime(true) 怎么用才不翻车
直接用 microtime(true) 是最轻量、最可控的起点，但错一步就白测：不传 true 会返回字符串，手动解析极不可靠；包进 echo 或 var_dump 会把 I/O 时间算进逻辑耗时；起止点没卡准，比如在函数调用前漏掉参数准备，或在结果赋值后还多跑了日志，测量值就失真。
必须做到：
- 始终用
microtime(true)，别用无参形式 - 起始点紧贴被测代码第一行，结束点紧贴最后一行执行完（例如
$result = some_func($input);后立刻记$end） - 单次运行毫无参考价值——系统调度、OPcache 是否命中、JIT 是否热启动，都会让结果差出 3–5 倍
- 至少循环 1000 次，取中位数（比平均值更抗异常值干扰）
- 每次循环内清空变量、避免引用复用，必要时加
gc_collect_cycles()
为什么不能开着 Xdebug 测性能
因为 Xdebug 会让所有函数调用慢 5–10 倍，不是“稍微拖慢”，是彻底改变调用开销比例。你测出来的 json_encode() 耗时可能主要来自 Xdebug 的钩子注入，而不是 JSON 序列化本身。结果不仅数值失真，连瓶颈位置都会误判——本该优化数据库查询，你却去改了一个根本没被放大的字符串拼接。
实操上必须：
- 确认
phpinfo()里xdebug.mode是off或未启用 - 禁用 IDE 的 Xdebug 自动连接（如 PHPStorm 的 “Start Listening”）
- 如果用 CLI 运行，检查是否带了
-dzend_extension=xdebug.so参数 - OPcache 也要留意：开发环境常关着，但生产默认开——基准测试应尽量贴近目标环境开关状态
phpbench 和手写循环差在哪
差在预热（warmup）、离群值剔除、统计归一化这些细节。手写 1000 次循环，第一次跑 array_merge() 很可能比第十次慢一倍，因为 OPcache 还没编译好；某次恰好撞上系统定时任务，耗时突增 20ms，拉高平均值——而 phpbench 默认做 3 轮 warmup，再采样 5 轮 × 1000 次，自动剔除最高最低 10% 数据，最后给标准差和相对误差。
快速上手要点：
- 安装：
composer require --dev phpbench/phpbench - 测试方法名必须以
bench开头，比如benchJsonEncode() - 加注解控制规模：
@Revs(1000)表示每轮跑 1000 次，@Iterations(5)表示共 5 轮 - 运行命令：
./vendor/bin/phpbench run --report=aggregate - 报告里重点关注
mode（最常见耗时）和std_dev（波动是否过大）
memory_get_usage() 测内存容易忽略什么
它只告诉你“当前分配了多少字节”，但不反映释放节奏。比如你在循环里反复 unset($bigArray)，memory_get_usage() 可能纹丝不动——PHP 的 GC 不是立即回收，而是延迟触发。更关键的是，它默认不包含未释放的内部缓冲区（如 cURL 的响应体缓存、PDO 的结果集缓冲），这些在真实请求中实际占着内存。
要得到有意义的数据，得配合：
- 用
memory_get_peak_usage()看整个过程峰值，比当前值更有预警意义 - 在关键节点前后都调用，比如 DB 查询前/后、大数组生成后、
unset()后，观察差值趋势 - 如果测 CLI 脚本，加
gc_collect_cycles()强制一次回收再查，否则 GC 延迟会让数据飘忽 - 注意单位：返回是字节，别忘了除以
1024 * 1024转 MB，否则看数字容易误判
真正难的不是记下怎么测，而是每次测试前问一句：这个测量方式，是否复现了线上最常发生的那个调用路径？比如测一个 ORM 方法，却用空数组当输入，那结果再快也没用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
