Symfony 异常监听核心是监听 kernel.exception 事件，在异常抛出但响应未生成前统一处理，适用于错误响应定制、日志增强和监控上报；需创建实现 onKernelException 方法的监听器类，正确注册为带 kernel.event_listener 标签的服务，并注意环境配置、优先级及响应设计。
写 Symfony 异常监听，核心是监听 kernel.exception 事件，在异常抛出但响应尚未生成前介入处理。它不是“捕获 try-catch 那种异常”，而是框架级统一拦截点，适合做错误响应定制、日志增强、监控上报等。
1. 创建监听器类
监听器需实现一个方法（如 onKernelException），接收 GetResponseForExceptionEvent 对象：
- 从事件中获取原始异常：
$event->getException() - 根据异常类型或业务逻辑决定如何响应：
instanceof YourCustomException - 调用
$event->setResponse($response)终止默认流程，返回自定义响应（如 JSON 错误结构） - 不调用
setResponse()则事件继续传播，可能被其他监听器处理，或最终交由 Symfony 默认错误页
2. 正确注册为服务
必须在 config/services.yaml 中显式声明，并打上事件标签：
- 标签必须是
{ name: kernel.event_listener, event: kernel.exception, method: onKernelException } - 确保类路径（
class:）正确，且命名空间与文件实际位置一致 - 若监听器依赖其他服务（如 logger、serializer），在构造函数中声明并配置自动注入
- 避免拼写错误：比如
kernel.event_listerner（少个 e）或kerenl.exception（typo）都会导致注册失败
3. 处理常见失效场景
监听器没触发？多数问题出在环境或配置细节：
- 开发环境下检查是否启用了
debug:container --env=dev | grep exception，确认服务已加载 - 生产环境默认禁用调试，
kernel.exception监听器仍有效，但错误页面可能被 Web 服务器（如 Nginx）提前拦截，需关掉fastcgi_intercept_errors off类设置 - 某些 bundle（如 FOSUserBundle）自带异常监听器，优先级更高，可能提前终止事件传播——加
priority参数提升你的监听器权重（如priority: 10） - 控制器中抛出的是 PHP 错误（E_WARNING）而非 Exception，
kernel.exception不会触发；此时需配合error_handler或启用convert_errors_to_exceptions
4. 响应设计建议
别只返回 500 页面，按场景区分处理：
- API 请求：返回标准 JSON 格式，含
code（业务错误码）、message、trace_id（用于日志追踪） - HTML 请求：可渲染自定义 Twig 模板，保留用户上下文（如当前路由、用户角色）
- 敏感信息过滤：生产环境禁止输出
$exception->getTraceAsString()，避免泄露路径或参数 - 记录关键日志：用
$logger->error('API error', ['exception' => $exception, 'route' => $request->get('_route')])
