不能直接拿，需从$request->attributes中提取路由名、控制器及参数等信息，因kernel.response触发时响应已生成，原始请求路径未变但路由匹配结果已存于attributes中。
kernel.response 事件能拿到最终生效的访问路径吗？
不能直接拿。kernel.response 触发时，响应已生成，Request 对象仍为原始请求路径（如 /admin/users），而实际被控制器处理的路由信息（如匹配到的 _controller、route 名、参数）早已在 kernel.request 阶段由 RouterListener 写入 $request->attributes —— 但这个属性在 kernel.response 里依然可用，只要没被中间层覆盖或清空。
怎么在校验逻辑里安全读取最终路由路径？
必须从 $request->attributes 中提取，而不是依赖 URL 或路由生成器。常见错误是试图用 $router->generate() 反推，这既不可靠又可能触发循环调用。
-
$event->getRequest()->attributes->get('_route')返回匹配的路由名（如app_user_list） -
$event->getRequest()->attributes->get('_controller')返回解析后的控制器字符串（如App\Controller\UserController::listAction） -
$event->getRequest()->attributes->get('id')可取路径参数（如/user/{id}中的值） - 若需完整“生效路径”语义（比如带 host、scheme 的绝对路径），应结合
$request->getSchemeAndHttpHost()+$request->getRequestUri()，但注意：这不是路由匹配结果，而是原始 HTTP 请求路径
为什么在 kernel.response 里改 Response 不影响路径校验逻辑？
因为路径校验本质是读操作，不修改请求上下文。但要注意两个坑：
- 某些安全监听器或中间件（如
Firewall）可能在kernel.response前已替换Response（如重定向到登录页），此时你看到的$event->getResponse()已不是原控制器返回的响应，但$event->getRequest()仍是原始请求对象，不受影响 - 若监听器中调用
$event->setResponse()，不会改变$request，所以路径信息依然可读；但若错误地调用$event->getRequest()->duplicate()并设新属性，可能丢失原始attributes
真正需要拦截路径变更的场景，该选哪个事件？
选 kernel.request，不是 kernel.response。比如你要拒绝所有未匹配路由的请求、或强制重写某类路径前缀，必须在控制器执行前干预：
- 在
onKernelRequest中检查$event->getRequest()->attributes->has('_route')判断是否路由命中 - 用
$event->setResponse(new RedirectResponse('/404'))提前终止流程，避免后续事件和控制器执行 -
kernel.response只适合做“事后审计”或“响应增强”，比如记录本次请求最终命中了哪个路由、添加 CORS 头、压缩输出等
最易忽略的一点：多个监听器共存时，RouterListener 的优先级是 32，你的校验监听器如果 priority ≤ 32，可能读不到 _route —— 必须设为 31 或更低（数字越小越晚执行），确保它在路由解析之后运行。
