应监听 kernel.controller 事件，此时 $request->attributes 已注入 _route 和 _controller，可安全获取路由名与控制器信息；需用 !$event->isMasterRequest() 过滤子请求，避免 _internal 等干扰。
不能直接“绑定控制器”到监听器——Symfony 2 的事件监听器（如 kernel.request）是全局触发的，它本身不感知具体路由或控制器方法。想精准定位某次请求对应哪个路由、哪个控制器，得靠日志上下文 + 请求对象解析，而不是靠监听器“绑定”。
监听器里怎么拿到当前匹配的路由和控制器？
监听器接收的是 RequestEvent（或旧版 GetResponseEvent），它只提供 $event->getRequest()。路由信息尚未注入请求对象，$request->attributes 在监听器执行时还是空的——因为路由匹配发生在监听器之后、控制器之前。
- ✅ 正确做法：监听
kernel.controller事件（不是kernel.request），此时 Symfony 已完成路由匹配，$event->getController()可取到目标控制器回调，$request->attributes->get('_route')和_controller也已写入 - ❌ 错误做法：在
kernel.request里查$request->attributes，大概率返回null - ⚠️ 注意：
kernel.controller是 Symfony 2.3+ 引入的，Symfony 2.0–2.2 需用kernel.request+ 手动调用RouterInterface::matchRequest()（性能差、不推荐）
如何在监听器中安全提取控制器类名和动作名？
kernel.controller 事件里的控制器值类型不固定：可能是数组 ['App\Controller\BlogController', 'showAction']，也可能是闭包或服务 ID 字符串。硬解构容易出错。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- ✅ 推荐方式：用
ControllerResolverInterface::getArguments()或直接读$request->attributes中的标准键 - ? 关键字段：
$request->attributes->get('_controller')（字符串形式，如App\Controller\BlogController::show），$request->attributes->get('_route')（路由名，如blog_show） - ? 小技巧：用
str_replace('::', '@', $controller)可快速转成服务 ID 格式，方便后续调试或权限检查
为什么日志里看到的路由名总是 _internal 或空？
这是常见陷阱：你监听了 kernel.request，但没意识到 Symfony 内部重定向（如异常页面、子请求）也会触发该事件。这些内部请求走的是 _internal 路由，和用户真实访问无关。
- ✅ 过滤真实请求：加判断
!$event->isMasterRequest()跳过子请求 - ✅ 区分主请求类型：检查
$request->getSchemeAndHttpHost() . $request->getRequestUri()是否符合预期域名/路径前缀 - ⚠️ 别依赖
$request->getPathInfo()单独判断——它不含查询参数，且对带前缀的部署（如 /app.php/xxx）可能失真
真正要“精准查看”，核心不在监听器绑定，而在选对事件时机、读对请求属性、过滤掉干扰请求。漏掉 isMasterRequest() 这一行，日志就全是噪音。
