Symfony 不支持用 kernel.controller 拦截请求，因其仅为通知性事件，无 setResponse() 或 stopPropagation() 接口；应改用 kernel.request 中间件、AccessDeniedException 或控制器基类前置校验。
Symfony 没有“控制器事件”这个官方概念，也没有 kernel.controller 这样的可监听、可中断的生命周期钩子——它只是一个通知性事件（KernelEvents::CONTROLLER），在控制器已被选中、但尚未执行时触发，**你不能在此事件中阻止控制器运行，也不能直接返回响应**。
为什么不能用 kernel.controller 拦截请求？
该事件本质是“控制器已确定，即将调用”的广播信号，不是拦截点。它的事件对象 ControllerEvent 不提供 setResponse() 或 stopPropagation() 接口。试图在这里返回错误或重定向，只会被忽略，后续控制器仍会照常执行。
真正能拦截控制器的替代方式
-
权限控制场景 → 抛出 AccessDeniedException：在控制器方法内或前置服务中校验头部、角色等，不满足则直接抛出
AccessDeniedException。它会被kernel.exception监听器捕获，自然转为 403 响应，且兼容 Symfony 的安全系统和日志链路。 -
统一前置校验 → 使用自定义中间件（RequestListener）：监听
kernel.request，在路由匹配前检查请求头、IP、Token 等。若校验失败，直接构造并设置响应：$event->setResponse(new JsonResponse(..., 401))，并调用$event->stopPropagation()阻止后续流程。 -
针对特定控制器类 → 在基类或 Trait 中统一校验：让需要保护的控制器继承一个带
__construct()或beforeAction()的基类，或使用#[Before]属性（需配合自定义处理器），把校验逻辑前置到控制器实例化或方法调用前。
典型头部校验示例（推荐用 kernel.request）
比如要求 BooksController 必须携带 X-API-User-Name: admin：
监听 kernel.request 的监听器中：
- 读取请求头：
$request->headers->get('X-API-User-Name') - 检查当前路由是否匹配
books_*类型（可用$request->attributes->get('_controller')判断） - 不满足条件时：
$event->setResponse(new JsonResponse(['error' => 'Unauthorized'], 401))并$event->stopPropagation()
不推荐的误区操作
- 在
kernel.controller中尝试$event->setController()替换为错误控制器：技术上可行但语义混乱，绕过正常异常处理流程，调试困难，且无法保证视图/模板层一致。 - 用
kernel.response修改 HTML 内容来“模拟拦截”：此时响应早已生成，只能做字符串替换，无法改变状态码、头信息或业务逻辑，纯属补救，不可靠。
