PHP 8.0 的致命错误（如 E_ERROR、E_PARSE）无法用 try/catch 捕获，必须通过 register_shutdown_function() + error_get_last() 组合兜底，因其发生在解析/执行底层中断阶段，不经过异常机制，且需最早期注册并校验错误类型。
PHP 8.0 的致命错误（如 E_ERROR、E_PARSE）无法用 try/catch 捕获，但可以通过 register_shutdown_function() + error_get_last() 组合实现“兜底捕获”，避免白屏或进程意外退出——前提是没在脚本中途被 exit() 或 die() 强制终止。
为什么 try/catch 对致命错误完全无效
致命错误属于 PHP 解析/执行阶段的底层中断，不经过异常处理机制。哪怕你在最外层包 try { require 'xxx.php'; } catch (\Throwable $e) { }，一旦 xxx.php 里有语法错误（E_PARSE）或调用不存在的函数（E_ERROR），脚本立刻终止，catch 根本不会触发。
常见误判场景：
- 把
Parse error: syntax error当成可捕获异常，结果日志空空、监控无响应 - 在 Composer 自动加载失败时依赖
catch处理，实际连类定义都没进到 - 认为
set_error_handler()能接管E_ERROR，但它只对非致命错误生效
register_shutdown_function() 是唯一可靠入口
它在脚本执行结束（无论正常退出、exit() 还是致命错误）后强制执行一次。配合 error_get_last()，就能拿到最后发生的致命错误信息。
立即学习“PHP免费学习笔记（深入）”；
关键实操要点：
- 必须在脚本**最早期**注册，比如
public/index.php开头，否则中间件或框架初始化失败时可能来不及注册 - 不要在 shutdown 函数里再抛异常或触发新错误，否则会覆盖原始致命错误信息
-
error_get_last()返回null表示无错误；返回数组时需检查['type']是否属于致命类型：E_ERROR、E_PARSE、E_CORE_ERROR、E_COMPILE_ERROR、E_USER_ERROR - 记录日志后，**显式调用
fastcgi_finish_request()（PHP-FPM 环境）或ob_end_flush()（CLI）**，确保日志写入不被阻塞
最小可用示例：
register_shutdown_function(function () {
if ($error = error_get_last()) {
$fatalTypes = [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR];
if (in_array($error['type'], $fatalTypes)) {
error_log(sprintf(
'[FATAL] %s in %s:%d',
$error['message'],
$error['file'],
$error['line']
));
// 可选：发送告警、清理临时文件、返回统一错误页
}
}
});
容易被忽略的三个崩溃点
即使加了 shutdown 捕获，以下情况仍会导致“捕获失败”或“服务不可用”：
-
memory_limit耗尽时，PHP 可能直接 segfault，register_shutdown_function()不执行——需靠系统级监控（如systemd的Restart=on-failure）兜底 - 扩展冲突（如旧版 Swoole 或 Xdebug）引发的段错误（
Segmentation fault），不属于 PHP 错误体系，error_get_last()返回null——要查core dump或禁用可疑扩展验证 - 致命错误发生在
register_shutdown_function()注册之前（例如php.ini加载阶段的extension=xxx.so崩溃），此时整个 PHP 进程已无法启动——只能靠 Web 服务器健康检查自动摘除节点
真正稳定的线上兜底，从来不是单靠一个函数，而是 shutdown 捕获 + 扩展兼容性验证 + 进程级健康探测三层覆盖。其中最容易被跳过的，是确认你用的所有 C 扩展都明确支持 PHP 8.0——哪怕文档没写，也要看它的 GitHub issue 里有没有 segfault 报告。
