最常见原因是PHP-FPM或Apache未加载修改后的php.ini，需在PhpStorm中确认CLI Interpreter配置文件路径；Xdebug 3需同时设xdebug.mode=profile和xdebug.start_with_request=trigger，并通过URL参数、Cookie或Header触发，且output_dir目录须对Web服务器进程可写。
为什么 cachegrind.out.* 文件没生成
最常见的情况是：你改了 php.ini，但 PHP-FPM 或 Apache 用的根本不是那个文件。在 PhpStorm 里按 Ctrl+Alt+S → PHP → 点击 CLI Interpreter 右侧的 ⚙️ → “Configuration file”，看到的路径才是 Web 请求实际加载的配置。Xdebug 3 必须同时满足两个条件才对 HTTP 请求生效：xdebug.mode=profile 且 xdebug.start_with_request=trigger（不是 yes）。否则只对命令行脚本有效。
触发方式有三种，任选其一即可：
- 浏览器访问时加 URL 参数：
?XDEBUG_TRIGGER=1 - 手动设置 Cookie：
XDEBUG_TRIGGER=1 - 用 curl 加 Header：
-H "XDEBUG_TRIGGER: 1"
别漏掉权限问题：xdebug.output_dir="/tmp/xdebug" 这个目录必须让 Web Server 进程（如 www-data、nginx）可写。用 sudo chown -R www-data:www-data /tmp/xdebug 比 chmod 777 更安全。
PhpStorm 打不开 cachegrind.out.* 怎么办
直接双击或拖进 PhpStorm 是打不开的——它不识别原始 cachegrind 格式。必须走专用入口：Tools → Analyze Xdebug Profiler Snapshot，然后手动选中那个 cachegrind.out.* 文件。
立即学习“PHP免费学习笔记（深入）”；
打开后默认是 Flat View，只列函数名和总耗时；真正要看调用链路，得切到 Call Tree 标签页。重点关注两列：
-
Inclusive Time：含所有子调用的总时间，高说明整个调用路径慢 -
Exclusive Time：仅函数自身执行时间，高才说明这行代码真慢
比如 Fqsen::__construct() 的 Inclusive 占比 28.7%，但 Exclusive 很低，说明它内部大量调用了正则 preg_match()，瓶颈不在构造器逻辑本身，而在字符串解析。
怎么看懂哪个函数才是真瓶颈
别只盯着顶部“耗时最长”的函数。高频小函数（如 array_merge() 被调 500 次）可能排不进前 10，但累计耗时惊人。一定要结合 Calls 列看频次。
另外，Xdebug Profiler 是函数级采样器，它告诉你 PDO::query() 耗了 800ms，但不会告诉你 SQL 有没有走索引、是否锁表、网络延迟多少。它也测不出 cURL 是卡在 DNS、连接、发送还是远端响应。这些得配合 MySQL 慢日志、EXPLAIN、curl -v 等工具交叉验证。
生成的文件太大或乱码怎么处理
大项目一次 profiling 可能生成上百 MB 的 cachegrind.out.*，既占磁盘又难加载。可以在 php.ini 中启用压缩：xdebug.profiler_output_name = cachegrind.out.%R.%t.gz（注意结尾加 .gz），Xdebug 会自动 gzip 压缩。
如果 PhpStorm 报“无法解析”或显示乱码，大概率是文件被截断或写入未完成。检查 Web Server 日志是否有“Permission denied”或“No space left on device”。临时把 xdebug.output_dir 改成一个绝对路径明确、空间充足的目录（如 /var/log/php-profiler），并确保 SELinux 或 AppArmor 没拦截写入。
