递归函数单次调用耗时需在入口和出口各调用一次 microtime(true) 并相减，配合 $depth 参数区分层级，避免仅测顶层或依赖 debug_backtrace()；调试阶段用条件开关控制日志输出，上线关闭；复杂场景优先使用 xdebug 或 Blackfire 等专业工具分析调用树与性能归因。
递归函数里怎么测单次调用耗时
直接在递归函数入口加 microtime(true)，出口再取一次，相减就是本次调用耗时。但注意：不能只测顶层调用，否则看不到深层递归的耗时分布。
常见错误是把计时逻辑写在递归外层，结果只拿到总耗时，漏掉中间各层的“热点”。真正要优化，得知道哪一层、哪个分支拖慢了整体。
- 每次进入函数就记录开始时间，存入局部变量或传参携带
- 返回前计算差值，可打印、写日志、或累加到全局统计数组
- 避免用
time()—— 精度只有秒级，递归通常远低于 1 秒 - 如果递归深度大，频繁调用
microtime()本身有微小开销，但对定位瓶颈影响极小
如何区分不同递归层级的耗时
靠递归深度参数（比如叫 $depth）配合计时数据，就能把耗时和调用栈位置对应起来。不传深度的话，所有调用看起来都一样，根本分不清是第 3 层还是第 12 层在卡住。
示例片段：
立即学习“PHP免费学习笔记（深入）”；
function calc($n, $depth = 0) {
$start = microtime(true);
if ($n <= 1) {
return 1;
}
$result = calc($n - 1, $depth + 1) + calc($n - 2, $depth + 1);
$elapsed = microtime(true) - $start;
error_log("depth={$depth}, n={$n}, time=" . sprintf('%.6f', $elapsed));
return $result;
}- 必须把
$depth作为参数显式传递并自增，PHP 不提供内置调用栈深度变量 - 不要依赖
debug_backtrace()实时获取深度——它本身比microtime()慢一个数量级，会严重污染测量结果 - 日志中保留
$n或其他关键参数，否则光看 depth 没法复现路径
避免递归计时干扰真实性能表现
计时代码本身会引入额外执行开销，尤其在高频浅层递归（如遍历树的叶子节点）中，可能让耗时翻倍。这不是 bug，而是测量副作用。
- 上线环境务必关闭耗时采集，只在调试阶段开启
- 用条件开关控制，比如
if (defined('DEBUG') && DEBUG)包裹计时逻辑 - 不要把耗时结果塞进返回值或修改原函数签名，否则容易引发下游逻辑异常
- 如果发现某层耗时异常高，先注释掉计时代码再跑一次——确认是逻辑问题，而非测量扰动
更轻量的替代方案：用 xdebug 或 blackfire
手动插桩适合快速验证某个函数，但想看清整个递归调用树、内存增长、函数调用频次，硬编码计时很快失控。这时候该换工具。
xdebug.profiler_enable 开启后生成的 cachegrind 文件，能直接在 QCacheGrind 里展开递归分支，每层的 self time、inclusive time、调用次数一目了然。
- 不用改任何 PHP 代码，只要配置好 xdebug 的输出路径和触发方式
- blackfire 更进一步，支持对比两次调用差异，精准指出“加了缓存后第 7 层耗时从 12ms 降到 0.3ms”
- 注意：xdebug 默认禁用递归深度限制（
xdebug.max_nesting_level），但过深仍可能被 PHP 自身的max_execution_time终止
递归耗时分析真正的难点不在“怎么测”，而在于“测完怎么归因”——同一层多个子调用，哪个分支是真瓶颈？是否重复计算了相同子问题？这些不会自动出现在时间数字里，得结合参数值和调用路径一起看。
