xdebug.filename_format已被废弃，实际生效的是xdebug.profiler_output_name；Xdebug 2.6+已移除该配置，仅支持xdebug.profiler_output_name及其占位符（如%p、%t、%r等），CLI下%R和%s不可靠。
xdebug.filename_format
已被废弃，实际生效的是
—— 这是很多人在配置 Xdebug 性能分析时第一步就卡住的根本原因。
为什么找不到 xdebug.filename_format？
从 Xdebug 2.6 开始，
就不再存在；官方文档和源码中均已移除。所有文件名控制逻辑统一收口到
。如果你在 php.ini 或 xdebug.ini 中写了这个配置项，它会被完全忽略，Xdebug 不报错也不警告，只会静默 fallback 到默认名
。
旧教程或迁移文档里残留的
是过期信息
Xdebug 3.x 完全不识别该指令，连 warning 都不输出
验证方式：执行
，检查输出里是否出现该配置项（不会出现）
真正可用的格式化占位符有哪些？
支持一组固定占位符，用于动态生成 cachegrind 文件名。常见组合包括：
：进程 ID（最稳定，避免并发覆盖）
：Unix 时间戳（秒级，适合按时间归档）
：随机数（4 位十六进制，防冲突）
：脚本 basename（不含路径，如
）
：请求 ID（需配合
或自动启用）
示例：
→ 生成
容易踩的坑：%R 和 %s 在 CLI 下失效
这两个占位符依赖 SAPI 环境上下文：
在 CLI 模式下始终为空字符串（除非手动设置
）
在 CLI 下取的是当前执行脚本名（如
），但若用
则为
，导致文件名非法
组合最稳妥：时间戳保证唯一性，随机数防秒级并发冲突
错误配置：
→ 所有 CLI 请求都写入
（空名），最终只保留最后一个分析结果。
压缩与文件名不能共存？
Xdebug 本身不支持直接在
中写
后缀来触发压缩。压缩由
的目录属性决定：
Linux/macOS：若目标目录挂载为 zfs/btrfs 并启用透明压缩，文件自然被压
Windows：NTFS 压缩需手动设置目录属性，Xdebug 不感知
真正可控的方式是后期用脚本批量 gzip：
注意：
会复用同一文件，此时
或
失效 —— 必须关掉它，否则多个请求混在一个文件里，WebGrind/KCacheGrind 解析失败。
真正要记住的只有两件事：删掉所有
，改用
；别信
在 CLI 下能工作，它大概率给你一个空字符串加一堆覆盖的文件。
xdebug.profiler_output_namexdebug.filename_formatxdebug.profiler_output_namecachegrind.out.%pxdebug.filename_formatphp --ri xdebugxdebug.profiler_output_name%p%t%r%sindex.php%Rxdebug.request_id_headerxdebug.profiler_output_name = cachegrind.out.%s.%t.%rcachegrind.out.index.php.1745734560.a3f1%R$_SERVER['REQUEST_ID']%stest.phpphp -r "..."-%t.%rxdebug.profiler_output_name = cachegrind.out.%Rcachegrind.out.xdebug.profiler_output_name.gzxdebug.profiler_output_dirfind /tmp/profiles -name "cachegrind.out.*" -exec gzip {} \;xdebug.profiler_append = 1%r%txdebug.filename_formatxdebug.profiler_output_name%R