kernel.request 事件不是中间件，真·中间件必须实现 Psr\Http\Server\MiddlewareInterface 并返回 ResponseInterface；错误当成中间件会导致链式调用失败、注册无效、调试不透明。
kernel.request 事件不是中间件，别把它当“Symfony 中间件”用 —— Symfony 6.x 里真·中间件必须基于 HTTP Kernel 的 RequestHandlerInterface 实现，否则就是事件监听器，行为、生命周期、错误处理全都不一样。
中间件类必须实现 RequestHandlerInterface，否则不是中间件
Symfony 6.x 官方文档明确要求：真正的中间件（Middleware）需实现 Psr\Http\Server\MiddlewareInterface，且其 process() 方法必须返回 ResponseInterface。很多人写了个监听 kernel.request 的服务，就自称“写了中间件”，结果发现无法链式调用、不能被 addMiddleware() 注册、调试时流程不透明。
正确做法是：
- 创建类并
use Psr\Http\Server\MiddlewareInterface和Psr\Http\Server\RequestHandlerInterface -
process()方法中必须调用$handler->handle($request)并返回其结果（或提前返回自定义Response） - 注册方式不是写
services.yaml监听事件，而是通过Kernel::configureContainer()或config/packages/framework.yaml的http_client/http_middleware配置项（注意：Symfony 6.3+ 才原生支持 middleware 配置，旧版需手动注入RequestStack+ 自定义处理器链）
示例片段（非事件监听器）：
namespace App\Middleware;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;
class CorsMiddleware implements MiddlewareInterface
{
public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
$response = $handler->handle($request);
return $response->withHeader('Access-Control-Allow-Origin', '*');
}
}
kernel.request 事件适合日志、审计、全局状态初始化
如果你只是想记录请求、收集指标、初始化上下文（如租户 ID、语言偏好），kernel.request 事件监听器更轻量、更稳定，也更符合 Symfony 原有设计范式。它不参与 PSR-15 请求处理链，因此不会影响响应生成顺序，也不会因中间件异常导致整个链中断。
常见误用场景：
- 在
onKernelRequest()里调exit或抛出未捕获异常 → 导致响应为空白页，且错误堆栈不进kernel.exception流程 - 试图在监听器里修改
$event->setResponse()后继续执行控制器 → 实际上控制器仍会运行，造成逻辑冲突 - 把权限校验放在这里，却没检查
$event->isMainRequest()→ CLI 命令、异步任务、子请求全部被拦截
安全做法：
- 只读取请求信息，不终止流程
- 需要阻断时，改用
Response+$event->setResponse()，并立即return - 加判断：
if (!$event->isMainRequest()) { return; }
中间件注册顺序决定执行时机，但响应阶段是逆序
Symfony 的中间件链是单向前向的，但响应阶段会倒着走回来 —— 这意味着你在中间件 A 中加的 header，在中间件 B 的响应阶段可能已被覆盖；而 B 中写的缓存头，可能被 A 的后置逻辑删掉。
典型陷阱：
- 日志中间件放在鉴权中间件之后 → 日志已打，但请求被拦，日志内容误导排查
- 压缩中间件（gzip）放在 CORS 中间件之前 → 响应体被压缩后，CORS 头虽存在，但浏览器因 Content-Encoding 不匹配拒绝解析
- Token 刷新中间件放在 API 路由中间件之后 → 刷新逻辑根本没机会触发
建议顺序（从外到内）：
- 请求预处理（CORS、gzip、body 解析）
- 认证（JWT 解析、Session 绑定）
- 权限（RBAC 检查、路由级白名单）
- 业务逻辑（控制器）
- 响应后处理（ETag、Cache-Control、日志）
中间件里拿不到 $this->container？别直接 new Service
Symfony 中间件默认不经过容器自动注入（除非你显式声明为服务并配置 autowire: true），所以 $this->container->get('logger') 或 new Logger() 都不可靠。尤其在 CLI 环境或子请求中，RequestStack 可能为空，SecurityContext 未初始化。
正确姿势：
- 构造函数注入所需依赖（
LoggerInterface、TokenStorageInterface等），由容器自动解析 - 避免在中间件里调
dump()或dd()—— 它会中断 PSR-15 链，导致ResponseInterface返回失败 - 若需访问用户信息，优先用
$request->getAttribute('user')（来自前置认证中间件注入），而非$this->tokenStorage->getToken()?->getUser() - 对异步任务或命令行调用，加
if (!$request->hasAttribute('user')) { return $handler->handle($request); }快速跳过
kernel.request 的价值在于框架底层可观测性与副作用控制。混淆二者，轻则功能失效，重则引发静默失败 —— 尤其在并发或 CLI 场景下，问题往往只在上线后才暴露。 
