xdebug 函数追踪不能直接检测死循环，但可通过高频重复调用、异常深缩进、毫秒级恒定时间差等痕迹暴露循环失控；需正确配置 xdebug.mode=trace、按需触发、指定可写日志目录；更高效方式是调低 xdebug.max_nesting_level 并捕获超限错误。
Xdebug 的函数追踪（function trace）本身不能直接检测死循环，但能暴露循环失控的痕迹——比如同一段代码反复调用、调用栈深度异常增长、或单次请求中函数调用次数远超合理阈值。
启用 Xdebug 函数追踪前必须确认的三件事
不是所有 Xdebug 版本都默认支持 trace_enable_trigger 或完整调用栈记录；PHP 进程需重启后配置才生效；追踪日志体积极易爆炸，绝不能在生产环境全量开启。
-
xdebug.mode必须包含trace（如xdebug.mode=develop,trace），仅设为debug不会记录函数调用 -
xdebug.start_with_request设为no，避免每个请求都写 trace 文件；改用xdebug.trigger_value配合 GET/POST 参数按需触发 -
xdebug.trace_output_dir要指向有写权限且空间充足的目录，否则 trace 写失败但 PHP 不报错，你会以为“没生效”
如何用 trace 日志定位疑似死循环的 PHP 脚本
死循环在 trace 日志里最典型的特征不是“无限长”，而是“高频重复模式”：同一函数反复出现、嵌套层级持续加深、或某段逻辑在毫秒级内被调用数百次。
- 用
grep -n 'function_name' /path/to/trace.xt查看目标函数出现频次和位置，若单个请求中出现 500+ 次，基本可判定失控 - 关注
=>缩进层级：正常脚本通常 ≤8 层，若看到连续 20+ 行缩进越来越深（如=> => => => ...），大概率是递归未终止或循环内反复 require - 对比时间戳列（trace 文件第 2 列）：若相邻两行时间差恒定在 0.000x 秒（如 0.000123、0.000124），说明代码在空转或极短周期轮询
比开全量 trace 更快的替代方案：用 Xdebug 的堆栈限制 + 报错捕获
与其等 trace 文件生成再分析，不如让 PHP 在循环过深时主动中断并报错——这比翻日志快一个数量级。
- 在
php.ini或运行时设置：xdebug.max_nesting_level = 200（默认 256，调低到 200 可更快暴露递归/循环嵌套失控） - 配合
set_error_handler()捕获E_ERROR，当看到 “Maximum function nesting level of '200' reached” 错误时，立刻检查报错行附近的while、for或函数调用链 - 对 CLI 脚本，加
-d xdebug.mode=develop,trace -d xdebug.start_with_request=yes临时跑一次，trace 文件名含 PID，方便快速对应
容易被忽略的关键点：trace 日志不记录 usleep/sleep，但会暴露它们的上下文
很多死循环靠 usleep(10) 降低 CPU 占用，看起来“不卡”，但 trace 日志里看不到 sleep，只看到 sleep 前后的函数反复进出——这是最危险的盲区。
例如：一个 while (true) { check_status(); usleep(10); }，trace 中只会密集出现几十上百次 check_status 调用，而 usleep 完全不记。你得结合进程状态（ps aux | grep php 看 R+ 状态）、CPU 使用率，再回溯 trace 中高频函数的源码逻辑，才能确认是否真在空转。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
