set_exception_handler必须在入口文件最顶部注册，否则自动加载失败、配置错误等早期异常无法捕获；它仅处理throwable，不捕获parseerror等解析期错误，需配合set_error_handler和register_shutdown_function兜底。
直接结论：不是“没捕获”，而是根本没注册处理器，或注册时机/范围不对——set_exception_handler() 必须在任何业务代码执行前、入口文件最顶部调用。
为什么 set_exception_handler() 没生效
常见现象是写了注册函数，但异常仍报 Fatal error: Uncaught exception 并终止脚本。本质原因不是函数写错了，而是它压根没被 Zend 引擎看到：
- 注册语句放在了自动加载器（如
composer/autoload.php）之后，而自动加载失败本身就会抛出ParseError或Error，此时处理器尚未就位 - 在某个类的构造方法或中间件里才调用
set_exception_handler()，但异常发生在该类初始化之前（比如配置文件语法错误、require失败） - Web 环境下用了 FastCGI 或 PHP-FPM，但入口文件（如
index.php）被框架路由重写绕过，实际执行的是另一个文件，而那个文件没注册处理器 - CLI 脚本中注册了，但异常发生在
pcntl_fork()子进程中——子进程不继承父进程的异常处理器，需单独注册
set_exception_handler() 能捕获什么，不能捕获什么
它只对 Throwable 生效（PHP 7+），但有明确边界：
- ✅ 可捕获：
Exception、RuntimeException、LogicException、TypeError、ArgumentCountError等所有Throwable子类 - ❌ 不可捕获：
ParseError（语法错误）、CompileError、E_ERROR级传统错误（如调用未定义函数）——这些属于编译/解析阶段失败，set_exception_handler()根本不会触发 - ⚠️ 注意：
set_error_handler()也不能捕获E_PARSE和E_COMPILE_ERROR，它们只能靠register_shutdown_function()+error_get_last()事后捞取
生产环境必须搭配的兜底组合
单靠 set_exception_handler() 远不够。真实线上崩溃往往来自更底层问题，必须三者并用：
- 在入口文件第一行注册
set_exception_handler()，参数必须是 callable（匿名函数或字符串函数名均可） - 紧随其后注册
set_error_handler()，将E_WARNING、E_NOTICE等转为ErrorException，再由异常处理器统一处理 - 最后注册
register_shutdown_function()，检查error_get_last()是否返回PARSE/COMPILE/FATAL错误，并记录日志、返回降级响应 - 所有日志写入必须用
error_log()或异步队列，避免在 shutdown 阶段再触发 IO 异常导致二次崩溃
最容易被忽略的细节
很多人以为注册完就万事大吉，但以下几点一错即失效：
-
set_exception_handler()回调内部不能再抛出未捕获异常——否则会直接 fatal，且无任何日志；回调里所有逻辑必须加try/catch包裹 - Web 环境下，回调中调用
http_response_code(500)是必要的，但不要依赖它自动设置 Content-Type；显式输出前应先header('Content-Type: application/json; charset=utf-8')，否则可能被浏览器当成 HTML 解析乱码 - 回调执行时原始调用栈已被销毁，
$e->getTraceAsString()是真实的，但无法访问任何局部变量或闭包上下文——想记录请求参数，必须提前在中间层存到全局变量或$_SERVER中 - CLI 脚本若使用
pcntl_async_signals(true)，信号中断也可能导致异常逃逸，需额外处理SIGUSR1等信号
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
