不能直接覆盖 Hyperf 默认异常类，否则会导致 Worker 崩溃、状态码错乱、日志失控及敏感信息泄露；应通过调试模式、启动日志、hyperf.log 和增强式继承 HttpExceptionHandler 等可控方式暴露底层错误。
直接覆盖 Hyperf 默认异常类来展示框架底层错误，不是推荐做法，容易导致 Worker 进程崩溃、状态码错乱、日志失控，甚至暴露敏感信息。Hyperf 的异常处理机制设计为“显式注册 + 顺序匹配 + 主动终结”，强行替换默认类会绕过这套安全链路。
为什么不能简单覆盖默认异常类
Hyperf 的 HttpExceptionHandler 是内置兜底处理器，负责：
- 识别
HttpException及其子类（如NotFoundException、MethodNotAllowedHttpException） - 自动映射 HTTP 状态码（404/405/422 等）并返回标准响应体
- 确保未捕获异常不穿透到 Swoole 层，避免进程退出
若用自定义类直接替换它，且 isValid() 判定过宽（例如返回 true 对所有 Throwable），会导致：
- 404 请求被当成 500 处理，前端收不到正确状态码
- 验证失败的
ValidationException被吞掉，返回空 JSON 或无errors字段 - 协程上下文丢失，日志无法关联请求 ID
正确暴露底层错误的替代方式
想看到框架级报错（比如容器注入失败、AOP 代理生成异常、配置加载中断），应通过以下可控手段：
-
启用调试模式：启动时加
--debug参数，Hyperf 会输出更详细的初始化错误和依赖解析失败原因 -
检查启动日志：运行
php bin/hyperf.php start后，首屏日志中会显示服务注册、注解扫描、连接池初始化等关键步骤的成败状态 -
查看 runtime/logs/hyperf.log：框架底层异常（如
ContainerException、ClassNotFoundException）默认会记录在此，比 HTTP 响应更早、更底层 -
临时增加兜底 ExceptionHandler：在
exceptions.php最末尾注册一个捕获Throwable的处理器，仅用于开发环境打印堆栈，生产环境必须禁用
如果真要定制底层错误展示
应在保留原有处理逻辑基础上做增强，而非覆盖：
- 继承
HttpExceptionHandler，重写handle()方法，在调用父类前/后插入日志或额外字段 - 在
handle()中判断是否为开发环境，是则附加getTraceAsString()到响应 body（注意脱敏） - 确保仍调用
$this->stopPropagation()，防止异常继续传递 - HTTP status 仍由父类决定，不手动改写
withStatus()，避免语义污染
哪些错误根本不在异常处理器范围内
以下情况不会进入任何 ExceptionHandler，覆盖类也无效：
- Swoole 启动失败（端口占用、扩展缺失）、PHP 解析错误（语法错、类未找到）——发生在框架加载前
- 协程内
exit()、die()、致命错误（Fatal error）——PHP 层面终止，不抛异常 - Redis 连接池初始化失败导致
async_queue消费者未拉起——属于进程启动阶段问题，日志在hyperf.log开头
