httpkernel::handle() 是请求处理唯一入口，按事件驱动分 kernel.request、kernel.controller、kernel.controller_arguments、kernel.view、kernel.response 五阶段调度，末尾可异步执行 kernel.terminate。
HttpKernel::handle() 是整个流程的唯一入口
所有 HTTP 请求最终都落到 HttpKernel::handle() 这个方法上，它不直接写业务逻辑，而是按固定顺序调度服务与事件。你写的控制器、路由配置、监听器，都是被这个方法拉起来的。调用时传入 Request 对象，返回 Response 对象，中间没有“跳过”环节——哪怕你返回一个空数组，也会被后续视图层兜底处理。
注意两个参数：$type 默认是 self::MAIN_REQUEST；$catch 控制是否捕获异常（生产环境通常为 true，避免未处理异常暴露堆栈）。子请求（如 ESI 片段）会传 self::SUB_REQUEST，此时部分事件（如 kernel.request）不会触发。
五个阶段对应五个核心事件节点
流程不是线性执行的 if-else，而是靠事件驱动推进。每个阶段广播一个标准事件，监听器可介入但不能阻断主链路（除非抛出异常或调用 stopPropagation()）：
-
kernel.request：刚拿到Request对象，还没匹配路由。适合做全局鉴权、语言切换、请求日志 -
kernel.controller：路由已匹配，控制器类和方法已确定，但尚未实例化。适合做参数预校验、权限细粒度拦截 -
kernel.controller_arguments：参数已由ArgumentResolver注入完毕，控制器即将被执行。这是修改控制器参数的最后机会 -
kernel.view：控制器已返回非Response类型（如数组、TemplateView），模板引擎还没开始渲染。适合统一包装 API 响应结构 -
kernel.response：响应对象已生成，但尚未发送。可安全修改头信息、替换内容体、注入 CSP nonce
别在 kernel.controller 里尝试返回 Response——事件监听器无权替代控制器职责，强行设响应会被忽略；真要中断，得抛 AccessDeniedException 或重定向到错误页。
控制器返回值决定是否走 kernel.view
控制器方法返回什么，直接决定流程是否进入视图阶段：
- 返回
Response实例 → 跳过kernel.view，直奔kernel.response - 返回数组、
string、null或TemplateView→ 触发kernel.view，交由 Twig 渲染或监听器接管 - 返回
RedirectResponse或JsonResponse→ 它们都是Response子类，同样跳过视图阶段
常见陷阱：用 $this->render() 返回的是 Response，不是模板路径字符串；若误写成 return 'default/index.html.twig';，就会触发 kernel.view 并报错“无法渲染字符串”。
kernel.terminate 是唯一异步执行点
kernel.terminate 在响应已发送给客户端后才触发，适合做耗时但不阻塞用户等待的操作：
- 记录完整请求耗时（含网络传输时间）
- 推送邮件或通知到消息队列
- 清理临时文件或会话数据
关键限制：Request 和 Response 对象在此时已不可靠——$event->getRequest() 可能为空，$event->getResponse()->isSent() 必为 true。不要试图读取 POST 数据或修改响应头，这些操作静默无效。
真正容易被忽略的是事件执行顺序与优先级的叠加效果。比如多个监听 kernel.response 的服务，优先级高的先执行，但它们看到的 Response 是前一个监听器修改后的结果。调试时用 php bin/console debug:event-dispatcher kernel.response 看注册顺序，比猜更可靠。
