解读

国内主流 PHP 框架（Laravel、ThinkPHP、Hyperf、Swoft 等）在启动阶段都会把「未捕获异常」统一接管，避免直接暴露给 FPM/CLI，从而保证日志格式统一、错误页友好、调试信息可开关。面试官问“注册时机”，实质想确认两点：

1. 框架生命周期里到底哪一步才真正调用 set_exception_handler；
2. 如果开发者自己再注册一次，会不会把框架的覆盖掉，导致日志或渲染链路失效。
   回答必须结合「入口文件 → 容器初始化 → 内核/服务提供者 → 中间件/请求循环」这一整条链路，并给出可落地的验证方式，才能体现“资深”。

知识点

1. set_exception_handler 是进程级函数，后注册者直接覆盖前者，返回旧处理器。
2. 框架启动顺序：
   a. 公共入口（public/index.php 或 bin/hyperf.php）加载 Composer 自动加载器；
   b. 实例化 Application/Container，注册内核（Kernel）；
   c. 内核 boot 阶段触发服务提供者（Provider）的 register → boot；
   d. 异常处理器一般作为「核心服务提供者」在 boot 阶段注册；
   e. 中间件、路由、请求循环随后才执行。
3. 注册方式：
   • Laravel：Illuminate\Foundation\Bootstrap\HandleExceptions::bootstrap() 在 Kernel 被 bootstrap 时注册；
   • ThinkPHP6：think\exception\Handle 类通过 app/ExceptionService::boot() 注册；
   • Hyperf：Hyperf\ExceptionHandler\ExceptionHandlerProvider::boot() 在 WorkerStart 事件后注册。
4. 覆盖风险：
   • 开发者在 config/app.php 或 provider 里再 set_exception_handler，会替换掉框架默认；
   • 正确做法是继承框架异常基类，通过框架提供的 report/render 钩子扩展，而不是裸调 set_exception_handler。
5. 验证方法：
   • 在 provider/boot 里打印 spl_autoload_functions 及 get_declared_classes，确认异常处理器类已加载；
   • 用 register_shutdown_function + debug_backtrace 打印调用栈，可精确定位 set_exception_handler 被调用的文件行号。

答案

以 Laravel 为例，set_exception_handler 的注册发生在「HTTP 内核」被 bootstrap 阶段，具体文件：
vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions::bootstrap()
触发顺序：
public/index.php → $kernel = new Illuminate\Foundation\Http\Kernel($app) → $kernel->handle($request) 之前，框架会先执行 $kernel->bootstrap()，其中第 5 个 bootstrapper 就是 HandleExceptions，它在内部调用 set_exception_handler([$this, 'handleException'])。
因此，只要开发者不在 provider/boot 或路由文件里再次覆盖，框架就能保证所有未捕获异常进入 Illuminate\Foundation\Exceptions\Report 和 render 链路。
如果业务需要自定义，应继承 App\Exceptions\Handler，重写 report/render 方法，或在异常监听器里做逻辑，而不是直接再次调用 set_exception_handler。

拓展思考

1. CLI 模式与 FPM 模式注册时机差异：
   Laravel 的 artisan 命令走 Console\Kernel，其 bootstrapper 列表同样包含 HandleExceptions，但输出格式由 Console\Output 决定；Hyperf 在协程池化场景下，set_exception_handler 需在 WorkerStart 之后、协程创建之前完成，否则子协程异常可能捕获不到。
2. Swoole 协程环境中，异常处理器需要同时注册 set_exception_handler 和 register_shutdown_function，因为致命错误会触发 shutdown，而非异常捕获链路。
3. 单元测试时，PHPUnit 自身也会注册异常处理器，框架为了隔离，会在 TestCase::setUp 阶段重新把 App\Exceptions\Handler 挂回去，避免日志双写。
4. 国内云原生部署（阿里云函数计算、腾讯云 SCF）会把 stderr 直接打到日志服务，若框架异常处理器未尽早注册，可能出现 500 但平台侧无堆栈的“黑屏”问题，因此官方镜像都把 HandleExceptions 提前到引导类最顶部。