关闭APP_DEBUG=1后，Web Profiler工具栏和/_profiler路由彻底失效，因ProfilerListener未注册、路由匹配日志被丢弃，非debug环境无现成替代方案；仅能通过prod日志记录$_route或dev环境下禁用toolbar但保留debug模式来绕行。
关闭 APP_DEBUG=1 后，Web Profiler 工具栏（WDT）和 /_profiler 路由会彻底失效——这不是“隐藏”，而是 Symfony 主动禁用整个调试栈。想在非 debug 环境下查看请求路径匹配结果，没有现成替代方案，只能绕行。
为什么关闭 debug 后看不到路由信息
Symfony 2 的 Profiler 组件与 kernel.debug 参数强绑定：一旦 APP_DEBUG=0，ProfilerListener 不注册，Router::match() 的详细日志、RequestContext 快照、_profiler 路由全部被跳过。不是前端没显示，是后端根本没采集。
-
APP_ENV=prod下，monolog默认只记录warning及以上级别，router.match这类 trace 级日志被直接丢弃 -
debug:twig、debug:router这些 console 命令仍可运行，但它们输出的是静态路由定义，不是本次请求实际匹配路径 - 即使手动在 prod 环境启用
profiler: true配置，也会因缺少ProfilerStorageInterface实现而报错：The profiler must be enabled.
dev 环境临时关闭 WDT 但保留路由调试能力
真正需要的不是“关闭 debug”，而是“不显示工具栏但保留数据采集”。这只需两步，不影响任何调试功能：
- 保持
APP_ENV=dev和APP_DEBUG=1不变——这是所有调试能力的基石 - 在
config/packages/dev/web_profiler.yaml中设toolbar: false，工具栏消失，但/_profiler/{token}依然可用 - 访问任意页面后，从 Network 面板复制响应头
X-Debug-Token的值，拼到https://your-app/_profiler/xxx即可查看完整路由匹配详情、控制器调用链、Twig 渲染树
prod 环境下硬查路由匹配的唯一可行方式
如果必须在 APP_DEBUG=0 下验证某 URL 是否命中某 controller，唯一可靠方法是加一行日志并触发请求：
- 在
src/Kernel.php的handle()方法末尾插入：$this->getContainer()->get('logger')->info('Current route: {route}', ['route' => $request->attributes->get('_route')]); - 确保
config/packages/prod/monolog.yaml中level: info或更低，并指向可写日志文件 - 发起请求后，立刻
tail -f var/log/prod.log查看输出——注意，_route是匹配成功后的结果，404时为null - 不要依赖
debug:router --show-controllers，它只列出注册路由，不反映实际匹配逻辑（比如 host、method、condition 过滤）
最易被忽略的点：很多人以为把 APP_DEBUG=0 改回 1 就能立刻看到 profiler，但若之前清过缓存或改过 kernel，必须执行 php bin/console cache:clear --env=dev，否则旧的 non-debug 编译容器仍在运行，kernel.debug 参数根本不会生效。
