Xdebug 3 profiling需同时满足四条件：xdebug.mode=profile、xdebug.start_with_request=trigger、?XDEBUG_PROFILE=1触发、xdebug.output_dir对Web进程可写；缺一不可，最常见失败原因是仅设mode而漏掉trigger。
Xdebug 3 的 profiling 不是配了 xdebug.mode=profile 就能出文件的，必须同时满足四个条件：模式开启、触发机制、输出目录可写、PHP 配置被真实加载。
为什么 cachegrind.out.* 文件始终不生成
最常见原因是只设了 xdebug.mode=profile，却漏了 xdebug.start_with_request=trigger。Xdebug 3 默认不会自动启动 profiling，哪怕你开了 profile 模式——它只在明确收到触发信号时才写文件。
-
xdebug.mode必须包含profile（如profile,develop），不能只写debug或空着 -
xdebug.start_with_request必须设为trigger（不是yes，也不是不设）；设成yes会强制所有请求都 profile，但极不推荐——磁盘和性能开销太大 - 浏览器访问时必须带
?XDEBUG_PROFILE=1参数，或手动设置 Cookie：XDEBUG_PROFILE=1；仅靠 URL 参数就足够，不用额外装插件 - 确认你改的是 PHP Web SAPI（如 Apache 或 PHP-FPM）实际加载的
php.ini，不是 CLI 的配置；用phpinfo()页面里的 “Loaded Configuration File” 路径为准
xdebug.output_dir 权限问题怎么查
即使参数全对，/tmp/xdebug 目录若对 Web 进程不可写，文件照样不会出现。Linux/macOS 下最直接的检查方式是：
Xdebug 3.4.1
下载
Xdebug 3.4.1 是一款功能强大的 PHP 调试扩展工具，于 2025 年 1 月 6 日正式发布。作为 Xdebug 3.4 系列的首个修复版本，3.4.1 版在继承上一版本强大功能的同时，重点解决了稳定性问题。该版本不仅修复了访问超全局变量时可能引发的程序崩溃现象，还增强了对 Windows 平台 PIE 构建机制的支持，为广大 PHP 开发者提供了更加稳定的调试环境。这一版本适合所有
- 运行
ps aux | grep -E "(apache|nginx|php-fpm)"看 Web 进程用户（常见为www-data、nginx或_www） - 执行
ls -ld /tmp/xdebug，确认该用户有写权限；没有就跑：sudo mkdir -p /tmp/xdebug && sudo chown www-data:www-data /tmp/xdebug（把www-data换成你的真实用户） - 别用
chmod 777，它可能被 SELinux 或某些容器环境拒绝；chown更稳妥 - Windows 下注意路径分隔符，
xdebug.output_dir="C:\tmp\xdebug"才合法，单斜杠或正斜杠都可能失效
PhpStorm 怎么正确打开 cachegrind 文件
双击 cachegrind.out.12345 文件？会失败——PhpStorm 不识别原始格式，必须走专用入口。
- 菜单栏选
Tools → Analyze Xdebug Profiler Snapshot，然后手动定位到那个文件 - 默认打开是
Flat View，只列函数总耗时；切到Call Tree才能看到完整调用链（比如Controller::index()→DB::query()） - 重点看两列：
Inclusive Time（含子调用时间）和Exclusive Time（纯自己代码时间）；如果某个函数Exclusive很低但Inclusive很高，说明瓶颈在它调用的下游（比如没索引的 SQL） -
Calls列不能忽略：一个array_filter()耗时 0.2ms，但如果被调 2000 次，总开销就是 400ms
profiling 的本质是函数级采样，它不会告诉你 SQL 为什么慢、cURL 卡在哪——它只告诉你 PDO::query() 执行了多久。真要定位数据库瓶颈，得结合慢日志、EXPLAIN 和连接池状态一起看。
