symfony请求生命周期是httpkernel::handle()驱动的可调试执行链，含kernel.request（request对象就绪）、kernel.controller（控制器确定）、kernel.controller_arguments（参数注入完成）、kernel.view（非response返回时触发）、kernel.response（响应发送前）和kernel.terminate（响应发出后）六大核心事件节点。
Symfony 的请求生命周期不是抽象概念，而是由 HttpKernel::handle() 驱动、可调试、可打断的真实执行链。你写的每一行拦截逻辑，都落在这个链条的某个明确节点上。
kernel.request 事件不是“刚收到请求”，而是 Request 对象已就绪的那一刻
很多人误以为 kernel.request 是原始 HTTP 数据刚进 PHP 的瞬间，其实此时 Request 对象已完成解析：方法、URI、查询参数、请求体（$request->getContent()）、上传文件、会话 ID 都已可用。但路由尚未匹配，控制器更没影子。
- 适合做：全局鉴权（如检查 API Token 头）、语言切换（
$request->setLocale()）、请求日志（记录$request->getMethod()和$request->getRequestUri()） - 不适合做：依赖路由参数的操作（比如读取
_route属性），它还不存在 - 注意：若在此阶段抛出
HttpException或调用$event->setResponse()，流程会跳过后续所有阶段，直接进入kernel.response
kernel.controller 和 kernel.controller_arguments 的分工很关键
kernel.controller 触发时，控制器类和方法已确定，但参数一个都没注入；而 kernel.controller_arguments 才是参数全部解析完毕、正要调用 action 前的最后关口。
-
kernel.controller：适合做控制器级权限校验（比如检查当前用户是否有访问该控制器的 ROLE_ADMIN） -
kernel.controller_arguments：适合做参数预处理（比如把$id字符串转成User实体，或对传入的DateTimeInterface参数统一时区归一化） - 两者都支持通过
$event->setController()替换控制器，但后者更常用于修饰参数数组（$event->getArguments()返回的是引用，可直接修改）
kernel.view 只在控制器返回非-Response 时触发
这是最容易被忽略的触发条件：只要控制器返回的是 Response 实例（包括 JsonResponse、RedirectResponse），kernel.view 就完全不广播。它只对数组、TemplateView、null 等“需要渲染”的返回值生效。
- 典型用途：统一包装 API 响应结构（比如把
['data' => $user]自动套上['success' => true, 'code' => 200, 'data' => ...]） - 陷阱：若你在
kernel.view中返回了Response，它会覆盖控制器原本的视图逻辑，但不会触发kernel.response—— 因为内核认为“响应已就绪”，直接跳转到发送阶段 - 兼容性注意：Symfony 6.4+ 默认启用
view事件，但若项目禁用了 Twig 或未配置视图层，该事件可能被静默跳过
kernel.terminate 不是“后台任务”，而是响应已发出后的唯一异步入口
kernel.terminate 在响应字节真正写入 socket 后才触发，此时连接可能已关闭，Request 和 Response 对象仍可读，但不能再修改响应内容（改了也没人收得到）。
- 安全用途：写审计日志（含耗时统计）、触发邮件队列、清理临时上传文件
- 绝对禁止：调用
$response->setContent()或尝试重定向 —— 这些操作无效且可能引发 warning - 性能影响：该事件监听器运行在 FastCGI/PHP-FPM worker 进程的“收尾阶段”，若阻塞太久（比如同步发邮件），会拖慢整个 worker 处理能力；务必用
exec('nohup php bin/console app:send-mail ... > /dev/null 2>&1 &')或消息队列解耦
真正难的不是注册监听器，而是判断哪个事件能拿到你需要的数据、又不会破坏已有流程。比如想给所有 JSON 响应加 X-App-Version 头，必须用 kernel.response；但若想根据路由动态决定是否压缩响应体，就得在 kernel.request 里提前标记，再在 kernel.response 里读取这个标记 —— 中间没有“跨事件传参”的魔法，只有你自己往 $request->attributes 里塞东西。
