PHP无法用try-catch直接捕获所有致命错误，因解析错误（E_PARSE）等发生在脚本执行前或运行时环境已崩溃，导致try-catch机制失效；但可通过set_error_handler处理非致命错误，set_exception_handler捕获未捕获的异常（包括PHP7+的Error），结合register_shutdown_function在脚本终止时调用error_get_last()获取致命错误信息，实现全面的错误记录与响应。
PHP本身无法直接用
try-catch捕获所有类型的致命错误（Fatal Error），特别是那些在脚本执行前或核心运行时发生的错误，比如解析错误（
E_PARSE）或内存耗尽（
E_ERROR中的一种）。然而，我们可以通过结合使用
set_error_handler()、
set_exception_handler()和
register_shutdown_function()这三种机制，构建一个相对完善的错误捕获与处理系统，从而“间接”感知并应对大部分致命错误，并对非致命错误和异常进行统一管理。
解决方案
要全面捕获并处理PHP中的错误，你需要策略性地部署以下机制：
-
自定义错误处理函数 (
set_error_handler
): 这个函数允许你接管PHP默认的错误处理机制，捕获像E_NOTICE
,E_WARNING
,E_USER_ERROR
等非致命错误，甚至在PHP 7+中，它还能捕获一些原本被认为是致命错误的E_RECOVERABLE_ERROR
（例如类型声明不匹配）。通过自定义函数，你可以将这些错误转换为异常抛出，或者直接记录到日志，避免它们直接暴露给用户。但请注意，set_error_handler
无法捕获E_ERROR
、E_PARSE
、E_CORE_ERROR
、E_COMPILE_ERROR
等最严重的致命错误。 -
自定义异常处理函数 (
set_exception_handler
): 当有未被try-catch
块捕获的异常（包括PHP 7+中的Error
类，它实现了Throwable
接口）发生时，set_exception_handler
注册的函数会被调用。这是一个处理所有“漏网之鱼”异常的最后一道防线，你可以在这里进行日志记录、错误页面展示等操作。getMessage() . " in " . $exception->getFile() . " on line " . $exception->getLine()); // 在生产环境，通常会显示一个友好的错误页面 // echo "抱歉，系统出了点小问题，请稍后再试。"; }); ?> -
注册关闭函数 (
register_shutdown_function
): 这是捕获那些最顽固、最致命的错误（如E_ERROR
、E_PARSE
、内存耗尽）的关键。register_shutdown_function
注册的函数会在脚本执行完毕或因致命错误而终止时被调用。在关闭函数中，你可以使用error_get_last()
来获取导致脚本终止的最后一个错误信息。这虽然不能阻止脚本终止，但能让你在脚本“死亡”后获取到错误详情，进行日志记录或通知。
结合这三者，你就能构建一个较为全面的错误捕获与处理体系。
为什么PHP不能直接用try-catch捕获所有致命错误？
说实话，这确实是很多初学者甚至一些经验丰富的开发者都会疑惑的问题。在我看来，这主要源于PHP错误处理机制的历史演进和不同错误类型的本质差异。
try-catch是为处理“异常”（Exceptions）而设计的，而PHP的致命错误（Fatal Errors）在很多情况下，其发生时整个脚本的执行环境已经处于一个不确定或不可恢复的状态了。
立即学习“PHP免费学习笔记（深入）”；
具体来说：
-
解析错误（
E_PARSE
）: 这类错误在PHP引擎尝试解析你的代码文件时发生，比如少了一个分号或括号。脚本根本就没能开始执行，try-catch
块自然也无从谈起。你可以想象，代码还没被理解，怎么能让它去执行捕获逻辑呢？ -
编译错误（
E_COMPILE_ERROR
）和核心错误（E_CORE_ERROR
）: 这些通常发生在PHP引擎内部，或者加载扩展时。同样，它们发生在脚本执行的早期阶段，或者直接破坏了运行时环境，使得try-catch
机制无法介入。 -
运行时致命错误（
E_ERROR
）: 比如调用一个不存在的函数、尝试实例化一个不存在的类（在PHP 7+中，这会抛出Error
异常，可以被try-catch
捕获，但在PHP 5中是E_ERROR
），或者内存耗尽。当这些错误发生时，PHP引擎可能会立即终止脚本的执行，不再执行后续代码，包括任何未完成的try-catch
块。引擎可能已经认为脚本无法继续安全运行，直接“拉闸断电”了。
PHP 7引入了
Throwable接口，统一了
Exception和
Error（
Error类继承自
Throwable），这使得许多以前是
E_ERROR的运行时致命错误现在可以被
try-catch捕获。例如，
new NonExistentClass()在PHP 7+中会抛出
Error，而不再是
E_ERROR。这无疑大大增强了
try-catch的捕获能力。但即便如此，像
E_PARSE或真正的内存耗尽这类错误，依然是
try-catch的盲区，因为它们发生的时机和性质决定了其无法被传统的异常处理机制所“挽救”。
如何利用register_shutdown_function“感知”并记录致命错误？
register_shutdown_function是我个人觉得在处理PHP致命错误时，最像“救命稻草”的一个机制。它就像一个守夜人，在脚本生命周期的最后时刻，无论脚本是正常结束还是意外死亡，都会被唤醒，给你一个机会去看看发生了什么。
它的工作原理是：你注册一个函数，这个函数会在PHP脚本执行完毕或被终止时自动调用。在你的关闭函数里，最关键的一步就是调用
error_get_last()。这个函数会返回一个数组，包含了导致脚本终止的最后一个错误的信息。如果脚本是正常结束，这个函数可能返回
null；如果是因为致命错误终止，那它就会返回错误类型、消息、文件和行号等宝贵信息。
这是一个实际的例子：
'E_ERROR',
E_PARSE => 'E_PARSE',
E_CORE_ERROR => 'E_CORE_ERROR',
E_COMPILE_ERROR => 'E_COMPILE_ERROR',
default => 'UNKNOWN_FATAL_ERROR'
},
$errorMessage,
$errorFile,
$errorLine
);
error_log($logMessage, 3, '/var/log/php_fatal_errors.log'); // 写入到指定文件
// 在生产环境，你可能还会发送邮件、Slack通知，或者上报到Sentry/Bugsnag等错误监控服务
// send_notification_to_admin($logMessage);
// 为了用户体验，可以在页面上显示一个友好的错误提示，而不是直接暴露PHP错误信息
// 当然，这要确保在HTTP头发送之后才能输出
// if (!headers_sent()) {
// http_response_code(500);
// echo "服务器内部错误
非常抱歉，我们遇到了一个问题，请稍后再试。
";
// }
}
});
// 制造一个运行时致命错误来测试
// 比如，调用一个不存在的函数（在PHP 5.x中会是E_ERROR，在PHP 7+中会是Error异常）
// 这里我们假设它会产生E_ERROR，或者一个未被捕获的Error异常最终导致脚本终止
// undefined_function_call();
// 制造一个内存耗尽的错误（这通常很难精确控制，但效果是类似的）
// ini_set('memory_limit', '8M'); // 临时设置一个很小的内存限制
// $largeArray = [];
// while (true) {
// $largeArray[] = str_repeat('A', 1024 * 1024); // 每次分配1MB
// }
// 制造一个真正的E_ERROR，例如：
// Class NonExistentClass {}
// $obj = new NonExistentClass(); // PHP 7+ 会抛出 Error，会被 set_exception_handler 捕获
// 如果是 PHP 5.x，这可能是 E_ERROR
// 为了演示 register_shutdown_function 捕获 E_ERROR，我们模拟一个更直接的场景
// 比如，尝试访问一个不存在的类的方法，且该类未被定义
// $object = null;
// $object->method(); // 这在 PHP 7+ 中通常会先抛出 TypeError，然后如果未捕获，则由 set_exception_handler 捕获。
// 如果是更底层的错误，或者发生在 set_exception_handler 自身出错，shutdown function 就会派上用场。
// 假设我们有一个语法错误的文件，require进来
// require 'syntax_error_file.php'; // 这会导致 E_PARSE 错误，shutdown function 可以捕获
// 正常执行的代码
echo "这段代码在致命错误发生前会执行。
";
// 故意制造一个会导致 E_ERROR 的情况（在PHP 7+中，很多 E_ERROR 变成了 Throwable 的 Error）
// 假设我们有一个资源句柄，但我们错误地把它当作对象来调用方法
$resource = fopen('php://memory', 'r');
// $resource->read(); // 这会导致 E_ERROR: Call to a member function read() on resource
// 对于 PHP 7+，这会抛出 TypeError，可以被 set_exception_handler 捕获。
// 所以，要真正演示 E_ERROR 被 shutdown function 捕获，需要一些更底层或者 set_exception_handler 自身失效的情况。
// 演示一个 PHP 7+ 中会被 set_exception_handler 捕获的 Error
// throw new Error("这是一个模拟的运行时致命错误，但现在是可捕获的Error");
// 为了确保 shutdown function 能捕获到一些“硬性”错误，
// 我们可以尝试在没有 set_exception_handler 的情况下，让一个 Error 浮出水面
// 或者模拟一个内存溢出，这通常是 E_ERROR
// ini_set('memory_limit', '16M');
// $bigString = str_repeat('A', 20 * 1024 * 1024); // 超过16M限制，会产生 E_ERROR
// echo "这段代码不会执行到";
// 一个更直接的 E_ERROR 例子：调用一个不存在的类的方法，如果该类未被定义，
// 并且这个错误没有被转换为 ErrorException 或被 try-catch 捕获
// 这在现代 PHP 中可能不容易直接产生 E_ERROR，因为很多都转成了 Error 异常。
// 但如果你的代码库里有老旧的逻辑，或者是在一些特定扩展里产生的底层错误，
// shutdown function 依然是最后的堡垒。
?>通过这种方式，即使脚本已经“死了”，你也能获取到它的“遗言”，这对于问题排查和系统稳定性至关重要。当然，它不能阻止脚本终止，但至少让你知道脚本为什么终止了，而不是一头雾水。
结合自定义错误处理与异常处理，构建健壮的错误报告系统
要构建一个真正健壮的错误报告系统，你需要将前面提到的所有机制有机地结合起来，形成一个多层次的防御体系。这不仅仅是技术上的堆砌，更是一种对系统稳定性和可维护性的深思熟虑。
在我看来，一个理想的错误处理流程是这样的：
最外层：
register_shutdown_function
它作为整个系统的“黑匣子记录员”。无论内部发生什么，它都是脚本生命周期结束时的最后一道防线。它只负责记录那些导致脚本彻底崩溃的致命错误（E_ERROR
,E_PARSE
等），不干预正常流程。这是你的底线，确保你不会对任何崩溃一无所知。中间层：
set_exception_handler
这是处理所有未捕获异常（包括PHP 7+中的Error
类）的统一入口。当你的代码中抛出了异常，但没有被任何try-catch
块捕获时，它会在这里被处理。这里通常会进行详细的日志记录（包含堆栈信息）、向开发者发送通知，并在用户界面上显示一个友好的错误页面，而不是技术细节。-
内层：
set_error_handler
它主要负责捕获非致命错误（E_NOTICE
,E_WARNING
等）和一些可恢复的错误。一个推荐的做法是，在自定义的错误处理函数中，将这些PHP错误转换为ErrorException
并抛出。这样，你就可以用统一的try-catch
块来处理它们，或者让它们最终被set_exception_handler
捕获，从而实现错误和异常的统一管理。这种“错误转异常”的策略，能让你的代码逻辑更清晰，也更容易进行单元测试。getMessage() . " in " . $e->getFile() . " on line " . $e->getLine() . "\n" . $e->getTraceAsString()); // 生产环境显示友好信息 if (!headers_sent()) { http_response_code(500); echo "系统内部错误
请联系管理员或稍后再试。
"; } }); register_shutdown_function(function () { $lastError = error_get_last(); if ($lastError && in_array($lastError['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])) { error_log("Fatal Error (Shutdown): " . $lastError['message'] . " in " . $lastError['file'] . " on line " . $lastError['line']); // 如果异常处理函数已经输出了错误页面，这里就不要重复输出了 // 否则，可以考虑再次输出一个通用错误页面 } }); // 业务代码中，可以使用 try-catch 捕获预期异常和转换后的错误 try { // 制造一个 E_WARNING $file = fopen('non_existent_file.txt', 'r'); // 会产生 E_WARNING，被 set_error_handler 转换为 ErrorException // 制造一个自定义异常 // throw new \Exception("这是一个自定义的业务异常"); // 制造一个 PHP 7+ 的 Error (例如类型错误) // function test(string $s) {} // test(123); // TypeError，会被 set_error_handler 捕获并转换为 ErrorException } catch (ErrorException $e) { // 捕获由 set_error_handler 转换而来的错误 error_log("Caught ErrorException: " . $e->getMessage()); // 可以根据错误类型进行更精细的处理 } catch (\Throwable $e) { // 捕获所有 Throwable，包括 Error 和 Exception
