Profiler工具栏不显示是因Symfony调试上下文未激活：需确保.env中APP_ENV=dev、APP_DEBUG=1，验证kernel.debug为true，检查模板含{{ render_profiler() }}，确认_profiler路由存在且响应头含X-Debug-Token。
Profiler 工具栏不显示，但页面能正常访问
这通常不是 FrankenPHP 的问题，而是 Symfony 的调试上下文没被正确激活。FrankenPHP 本身不干涉 PHP 的 $_SERVER 变量注入逻辑，但它默认以 production 模式运行——哪怕你本地用 frankenphp serve 启动，APP_ENV 和 APP_DEBUG 若没显式设为 dev/1，Kernel 就不会加载 WebProfilerBundle。
检查点如下：
-
.env文件中必须有APP_ENV=dev和APP_DEBUG=1，且不能被.env.local或运行时环境变量覆盖 - 执行
php bin/console about，确认输出里Environment是dev、Debug是true - 在控制器里加
dump($this->getParameter('kernel.debug'))，输出必须是true；如果为false，说明 Kernel 构造时已跳过调试模式初始化 - FrankenPHP 的 CLI 模式（
frankenphp serve）不会自动读取.env—— 你得手动传：APP_ENV=dev APP_DEBUG=1 frankenphp serve
页面底部无 <script id="sfwdt">，Network 中也看不到 _profiler 请求
说明 Profiler 的响应注入流程被截断。FrankenPHP 使用 SAPI 模式运行 PHP，不经过 Apache/Nginx 的输出缓冲层，所以常见于 ob_end_clean()、exit、或模板里漏掉 {{ render_profiler() }} 的问题会更“硬性”地生效。
排查顺序：
立即学习“PHP免费学习笔记（深入）”；
- 打开主 Twig 模板（如
templates/base.html.twig），确认</body>前有{{ render_profiler() }}（不是include，也不是注释掉的） - 检查是否在 Controller 或事件监听器里调用了
ob_end_clean()、ob_flush()或die/exit—— FrankenPHP 下这些会直接终止响应流，Toolbar 脚本根本不会写入 - 运行
php bin/console debug:router | grep profiler，必须看到类似_profiler_home、_profiler_search的路由；若为空，说明web_profiler.yaml没被加载或被路由配置覆盖 - 确认
config/routes/dev/web_profiler.yaml存在且内容为：web_profiler: resource: '@WebProfilerBundle/Resources/config/routing.xml'
工具栏显示了，但点击后跳转 404 或空白页
这是 FrankenPHP 的路由匹配机制和 Symfony Profiler 路由前缀冲突的典型表现。FrankenPHP 默认把所有请求都转发给 public/index.php，但它的内部重写规则可能未保留原始 PATH_INFO，导致 /_profiler/xxx 被当作静态资源处理，或被 index.php 的 front controller 逻辑忽略。
解决方案聚焦在入口配置：
- 确保
public/.frankenphp.frpc（或frankenphp.yaml）中启用了rewrite规则，例如：rewrite: - from: "^/_profiler/(.*)$" to: "index.php" type: "prefix" - 若用
frankenphp serve，它默认使用内置规则，但会忽略非/开头的路由 —— 此时必须加--router参数指向自定义路由文件 - 临时验证：手动访问
http://localhost:8080/_profiler/（注意末尾斜杠），看是否返回 Profiler 首页；如果 404，说明路由未透传；如果返回 HTML 但无数据，检查X-Debug-Token响应头是否存在 - FrankenPHP v1.2+ 支持
fastcgi_finish_request()，但 Profiler 数据采集依赖此函数完成异步写入；若你禁用了它（如在php.ini中关了output_buffering），_profiler页面可能加载空数据
Profiler 数据存在，但工具栏图标不刷新、SQL 查询数始终为 0
这往往不是加载失败，而是 Profiler 的收集器（Collector）没被触发。FrankenPHP 在 CLI 模式下默认启用 OPcache，而某些 Collector（如 DoctrineDataCollector）依赖运行时反射，在 OPcache 全启用且未预热时可能跳过初始化。
关键干预点：
- 在
config/packages/dev/web_profiler.yaml中显式启用关键收集器：web_profiler: toolbar: true intercept_redirects: false collect: true - 检查
php --ini加载的php.ini，确认opcache.enable_cli=1未被设为0；若设为 0，FrankenPHP 会退回到解释执行，Collector 可能因类未完全加载而失效 - 运行
php bin/console debug:container --tag=debug.data_collector，确认data_collector.doctrine、data_collector.twig等服务存在且未被移除 - 最隐蔽的坑：FrankenPHP 的 worker 模式下，每个请求可能复用同一个 PHP 进程，若上一个请求的 Profiler 数据未清理干净（比如异常中断），新请求的 Collector 可能拒绝覆盖旧数据 —— 此时重启 FrankenPHP 进程是最直接的验证方式
FrankenPHP 对 Profiler 的支持是完整的，但它的“零配置启动”假定你已处于标准 Symfony dev 环境；一旦路径、环境变量、OPcache 或输出控制链路中任一环没对齐，问题就表现为“加载失败”，而实际是某处静默跳过了 Profiler 初始化流程。
