启用Xdebug性能分析需设xdebug.mode=profile（PHP 8.0+），配置xdebug.output_dir并确保可写，用qcachegrind等工具解析cachegrind文件，关注Inclusive/Self Time，严禁用于线上，推荐microtime或getrusage作轻量替代。
怎么开 Xdebug 性能分析（不是调试）
Xdebug 默认关着性能分析，光装好没用。必须显式启用 xdebug.mode=profile，不是 debug 或 develop —— 这是最多人卡住的第一步。
-
xdebug.mode必须设为profile（PHP 8.0+），旧版用xdebug.profiler_enable=1，但已弃用 - 只靠
xdebug.start_with_request=yes不够，它默认只对 CLI 生效；Web 请求需配合xdebug.profiler_enable_trigger=1+ GET 参数XDEBUG_PROFILE - 输出文件默认在
/tmp，权限不对会静默失败（尤其 Docker 或非 root 用户），建议显式设xdebug.output_dir=/var/tmp/xdebug-profile并确保可写
生成的 cachegrind 文件怎么读
文件名像 cachegrind.out.12345，不是直接打开看文本——那是结构化数据，得用支持 cachegrind 格式的工具解析。
- 本地开发推荐
qcachegrind（Linux/macOS）或WinCacheGrind（Windows），别用文本编辑器硬啃 - 关键字段看
Inclusive Time（含子函数耗时）和Self Time（仅本函数执行时间），后者更能定位热点 - 注意 PHP 内置函数（如
json_encode、file_get_contents）也会被计时，别一看到高耗时就怀疑自己代码，先确认是不是 I/O 或序列化瓶颈
profile 开着会影响线上服务吗
影响非常大，不是“有点慢”，是典型「开着就别上生产」的配置。
- 每个请求都会写磁盘，高频服务下可能打满 I/O，甚至触发
open_basedir或磁盘配额限制 - PHP 进程内存占用翻倍以上，
opcache效果也会打折，因为 Xdebug 会绕过部分优化路径 - 绝对不要用
xdebug.start_with_request=yes配合 auto_prepend_file 一类方式“偷偷开”，Apache/Nginx 子进程继承后全量生效，比想象中更难控制
替代方案：轻量级函数级耗时统计
真要线上临时查瓶颈，xdebug.mode=profile 太重，改用内置函数组合更可控。
立即学习“PHP免费学习笔记（深入）”；
- 用
microtime(true)手动包住可疑代码段，配合日志记录，简单粗暴但有效 -
getrusage()可取进程级 CPU/内存使用，不依赖扩展，适合定时采样 - Laravel 等框架自带
Debugbar或clockwork，它们用的是钩子 + 内存缓冲，不落盘，适合灰度环境小流量观察
profile 文件本身不压缩、不轮转，一个 10 分钟的请求可能生成上百 MB 的 cachegrind，清理不及时会吃光磁盘——这点常被忽略，直到监控报警才反应过来。
