如何优雅地处理 PHP 中的致命错误与异常恢复策略

写 PHP 的人，几乎都曾在深夜被一个 `Fatal error` 拍在脸上。它不像普通异常那样可以被 `try...catch` 温柔地兜住，而是直接击穿脚本，留下一地鸡毛。很多开发者的第一反应是“这玩意儿根本无法恢复，听天由命吧”，但事实真的如此吗？

在 PHP 7 以前，致命错误确实是职业生涯的“终结者”。但 PHP 7 之后，情况发生了根本性转变 —— 大部分致命错误已经变成了 `Error` 类的实例，可以被捕获，甚至可以制定优雅的恢复策略。真正的问题，往往出在我们选择“如何面对它们”的态度上。

打破偏见：致命错误并非全是“必死局”

传统的认知里，`E_ERROR` 类型的错误（比如调用不存在的函数、类不存在、内存耗尽）意味着请求的终结。但在 PHP 7+ 中，这些错误被划归到 `Throwable` 接口下，与 `Exception` 并驾齐驱。

这意味着什么？意味着**除了内存耗尽这类极个别情况，其余绝大多数致命错误，都可以被 `catch (\Throwable $e)` 捕获**。如果你还在用 `catch (\Exception $e)` 处理全局异常，那你就错过了所有 `Error` 级别的拦截，它们依然会悄无声息地搞垮你的页面，表现为白屏、死链接，或者给用户留下一个寂寞的 500 页面。

所以，优雅处理的第一步，是把视野从 `Exception` 拓宽到 `Throwable`。

全局兜底：不要让错误裸奔

很多框架已经做好了全局异常处理，但如果你在写原生脚本，或者想要更精细的控制，一套“防线”至关重要。

我们不指望每一段业务代码都包裹 `try...catch`，更理智的做法是设置全局的异常与错误拦截器。在 PHP 中，理想的三重奏是这样的：

1. `set_error_handler()`：用来处理非致命错误（Warning/Notice）。你可以在这里将其统一转成 `ErrorException` 抛出，交给上层逻辑处理。
2. `set_exception_handler()`：处理所有未被捕获的 `Throwable`。这是请求终止前的最后一道防线。在这里，你不应该试图“解决”错误，而是应该记录日志、渲染一个友好的错误页面（而不是显示路径和下划线）、并终止请求。
3. `register_shutdown_function()`：针对最后的致命逃生通道（比如内存溢出无法抛出对象）进行最终检查。此处通过 `error_get_last()` 检测是否发生致命错误，做最后的重度日志记录。

这三者搭配起来，就构建了一个坚不可摧的“错误防御矩阵”。

从崩溃中恢复：重试还是降级？

有了捕获能力，我们就可以谈“策略”了。处理致命错误的关键，在于评估资源的完整性。

当一个 `Error` 被抛出时，比如某个扩展函数缺失，这往往是环境问题，重试一万次也没用。此时你最该做的是服务降级：比如关闭渲染重引擎的功能，并输出错误页面，同时向开发者邮箱发送告警。

但有些`Throwable` 场景下，我们可以“软着陆”。比如我们在调用一个不必要的第三方 API 时，如果对方接口超时引发了 `Error`，我们可以捕获后，在日志中标记，并返回上一次缓存的 JSON 数据。这种“有损恢复”策略，比起代码崩溃带来的体验损毁，要优雅一万倍。

千万不要做的是： 在 `catch` 块中强行“忽略”错误并继续执行后续逻辑。倘若状态机已经被破坏，比如数据库连接半开、文件句柄失效，继续硬着头皮跑下去，只会引发更深层的连带灾难，最终产生难以排查的横切性 Bug。

聊聊优雅的代码姿势

下面是一段经过打磨的顶层兜底逻辑片段，能帮你直观地感受这种策略的落地：

// 将普通错误（Warning等）转为异常，以便统一处理
set_error_handler(function ($severity, $message, $file, $line) {
    throw new ErrorException($message, 0, $severity, $file, $line);
});

// 顶层异常捕获器
set_exception_handler(function (\Throwable $e) {
    // 1. 记录充满上下文的日志
    \Log::error($e->getMessage(), [
        'file' => $e->getFile(),
        'line' => $e->getLine(),
        'trace' => $e->getTraceAsString(),
    ]);

    // 2. 区分正常请求与命令行，渲染不同响应
    if (PHP_SAPI === 'cli') {
        fwrite(STDERR, "致命错误: " . $e->getMessage());
    } else {
        http_response_code(500);
        // 3. 输出标准化的JSON或漂亮的生产错误页，不泄露堆栈
        echo json_encode(['code' => 500, 'message' => '系统繁忙，请稍后再试。']);
    }
});

这套代码的核心思路并非“让程序不报错”，而是接收毁灭，把损失记入历史，将体验还给用户。理解了这一点，你就不再是被 Fatal Error 追赶着跑的菜鸟，而是能够拿着扳手维护大型系统的工程师。

最后送你一条建议：在开发阶段，请关掉这个兜底页面，让错误大声尖叫出来；在生产环境，才把它调教成得体而安静的管家。所谓优雅，无非是在该崩溃的时候明确崩溃，在该体面的时候坚定不移地体面。