Symfony异常处理走PHP错误处理器+kernel.exception事件双通道，中间件不参与未捕获异常处理；应使用ErrorEnhancerInterface增强异常或kernel.exception监听器定制响应。
Symfony异常处理不靠中间件实现，自定义异常逻辑不该塞进中间件里。 它走的是 PHP 错误处理器注册链（set_exception_handler）+ 内核异常监听器（kernel.exception 事件）双通道，中间件（kernel.request 层）在异常抛出后根本不会被执行。
为什么中间件不适合处理未捕获异常
中间件是请求生命周期中「正常流程」的一环，只在 kernel.request 到 kernel.response 阶段运行。一旦控制器或服务中抛出未捕获异常，内核会立即跳过后续中间件，直接触发 kernel.exception 事件。你写的中间件里的 try/catch 只能捕获自己内部抛出的异常，对控制器层崩溃完全无效。
- 写在中间件里的
try { $next($request); } catch (\Throwable $e) { ... }只包裹了$next()调用，但无法覆盖控制器执行栈 - 生产环境开启 OPcache 后，中间件异常捕获还可能因字节码优化导致堆栈截断，错误定位更难
- 框架自带的
ErrorHandler已接管所有E_ERROR、E_PARSE和未捕获Exception，重复注册中间件 handler 会造成行为冲突
真正该用的两个扩展点
要增强异常行为，必须用对位置：一个是 ErrorEnhancerInterface（增强异常对象本身），另一个是 kernel.exception 事件监听器（干预响应生成）。
-
ErrorEnhancerInterface：适合给异常“加料”，比如把PDOException补充数据库连接参数、当前 SQL、主机名等上下文，它在异常被渲染前调用，返回增强后的\Throwable -
kernel.exception监听器：适合做响应劫持，比如对AccessDeniedException统一重定向到登录页，或对 API 请求返回 JSON 错误结构 —— 注意：这里不能throw新异常，否则会二次触发事件，应直接$event->setResponse(...)
自定义 ErrorEnhancer 的实操要点
写一个 DatabaseErrorEnhancer 时，别只检查 PDOException 类型，还要确认它来自当前应用主连接（避免捕获 Doctrine 迁移或命令行工具的连接错误）。
- 通过
$error->getMessage()判断是否含"SQLSTATE"或"Connection refused"等特征，比单纯instanceof更可靠 - 增强后的异常必须保持原有类型，否则
SerializerErrorRenderer可能无法识别 HTTP 语义（如 503 vs 500） - 不要在
enhance()里做日志记录或发 HTTP 请求 —— 这里要求轻量、无副作用，耗时操作应交给事件监听器或日志处理器
kernel.exception 监听器里容易踩的坑
监听器里最常犯的错是手动构造响应但忽略了格式协商（Accept 头）和环境适配。
- 别硬编码
new Response(json_encode([...]), 500)，应复用SerializerErrorRenderer或HtmlErrorRenderer的render()方法获取FlattenException，再按需包装 - 开发环境（
APP_ENV=dev）下，监听器返回的响应会被HtmlErrorRenderer覆盖 —— 所以监听器只应在prod或test环境生效，用$this->environment !== 'dev'做守卫 - 监听器优先级设太高（如
256）可能抢在安全组件之前执行，导致AccessDeniedException被你提前吞掉，用户收不到 403
异常处理的复杂点从来不在“怎么写代码”，而在于分清「谁在什么时机、以什么身份介入」—— ErrorHandler 是守门人，kernel.exception 是调度员，中间件只是办事员，别让办事员去干守门人的活。
