xdebug profiler 不自动识别慢请求，因它无内置慢查询判断逻辑；需手动在入口文件用 microtime 计时或结合 mysql 慢日志触发 xdebug_start_profiling()，并确保 mode=profile 且 output_dir 可写。
为什么 xdebug.mode=profile 不能自动识别“慢请求”
Xdebug Profiler 本身不判断“快慢”，它只按配置触发采样。设 xdebug.mode=profile 后，若没配触发逻辑，它要么全开（污染日志、拖慢响应），要么完全不生成文件——它不会读取 long_query_time 或监控 SQL 执行时间来决定是否 profiling。
用 xdebug.start_with_request=trigger + 自定义条件拦截慢请求
真正的控制点在触发逻辑：你得自己写 PHP 代码判断当前请求是否“慢”，再手动调用 xdebug_start_profiling()。Xdebug 不提供内置的“慢请求自动 profiling”开关。
Xdebug 3.4.1
下载
Xdebug 3.4.1 是一款功能强大的 PHP 调试扩展工具，于 2025 年 1 月 6 日正式发布。作为 Xdebug 3.4 系列的首个修复版本，3.4.1 版在继承上一版本强大功能的同时，重点解决了稳定性问题。该版本不仅修复了访问超全局变量时可能引发的程序崩溃现象，还增强了对 Windows 平台 PIE 构建机制的支持，为广大 PHP 开发者提供了更加稳定的调试环境。这一版本适合所有
- 在入口文件（如
public/index.php）顶部加判断逻辑，例如检查 MySQL 查询总耗时 > 500ms、或请求总响应时间预估超阈值 - 用
microtime(true)记录起始时间，在响应前计算差值，满足条件则调用xdebug_start_profiling() - 注意：必须确保
xdebug.mode已包含profile，且xdebug.output_dir可写，否则调用无效 - 别在框架中间件里调用
xdebug_start_profiling()后忘了xdebug_stop_profiling()，否则可能跨请求污染
更稳妥的做法：结合慢查询日志反向触发 profiling
MySQL 的 slow_query_log 是真实反映慢 SQL 的来源。你可以让应用在检测到慢查询后，主动开启 profiling 并打上标记，方便后续归因。
- 在 PDO/MySQLi 封装层中，捕获执行时间 >
long_query_time的语句（比如用mysqli->query()包裹计时） - 命中慢查询时，设置一个请求级 flag（如
$_SERVER['XDEBUG_PROFILE_SLOW'] = true） - 在请求结束前检查该 flag，为真则调用
xdebug_start_profiling(null, ['output_name' => 'cachegrind.out.slow.%R.%t']) - 这样生成的文件名带
slow前缀，和普通 profiling 文件区分开，避免混淆
别依赖 ?XDEBUG_PROFILE=1 做慢请求筛选
这个参数只是手动触发开关，和“慢”无关。它适合临时调试单个请求，但无法自动化匹配性能问题场景。
- 浏览器加
?XDEBUG_PROFILE=1只是告诉 Xdebug “这次要 profile”，不校验耗时、不关联数据库行为 - 如果想批量复现慢请求，应优先用压测工具（如
ab或hey）配合慢查询日志定位 URL，再针对性加触发逻辑 - 生产环境禁用该参数，防止被恶意利用导致磁盘爆满或拒绝服务
PDO::query() 耗了 800ms，但不知道是哪条 SQL、有没有索引、是否锁表——必须把 cachegrind 结果和 MySQL 的 slow_query_log、EXPLAIN 输出交叉比对，才能闭环定位。
