php错误和异常如何处理_trycatch与错误报告设置【详解】

try...catch仅能捕获Exception及其子类（如RuntimeException），无法捕获E_ERROR、E_PARSE、E_WARNING等传统错误；Fatal error需用register_shutdown_function兜底，但不可恢复执行。

先说一个很多人容易混淆的点：PHP里的错误和异常，根本就是两码事。如果试图用 try...catch 包揽所有报错，那致命错误会直接漏掉，而 E_NOTICE 这类警告它也拦不住。所以必须搞清楚：哪些能捕，哪些得靠错误处理器或配置来管。

哪些错误能被 try...catch 捕获？

try...catch 这个机制，只对 Exception（以及它的子类，比如 RuntimeException）有反应。对于传统意义上的 PHP 错误——比如 E_WARNING、E_NOTICE、E_ERROR——它完全无能为力。

很多人会误以为“加了 try 就万事大吉”，但现实很残酷，下面这些情况照样会中断执行，而且 try 根本抓不住：

• parse error（语法错误）：这发生在编译阶段，脚本还没跑起来就已经失败了，try 根本没机会登场。
• Fatal error（比如调用一个不存在的函数 undefined_function()）：执行到这一行就直接终止，不会抛异常。
• Warning 或 Notice：默认情况下，它们只是输出一个提示，既不中断执行，也不会进入 catch 块。

所以，如果真想用 try...catch 来兜住某段可能出问题的代码，唯一的办法是先把它包装成一个异常，让原本的错误“升级”成异常才行：

function riskyOperation() {    if (!is_readable('/path/to/file')) {        throw new RuntimeException('File not readable');    }    return file_get_contents('/path/to/file');}try {    $data = riskyOperation();} catch (RuntimeException $e) {    // 这里才能捕获到}

如何让传统错误转成异常？

PHP 里有一个利器：set_error_handler()。这个函数可以把大部分运行时错误（除了 E_ERROR、E_PARSE 等极少数之外）都转成 ErrorException 的实例，然后就能被 try...catch 优雅地处理了。

这里有几个关键点需要注意：

• 它仍然无法捕获 E_ERROR、E_PARSE、E_CORE_ERROR 这类致命错误，它们级别太高，根本进不了这个处理器。
• 必须配合 error_reporting() 的配置来用，否则如果某个级别的错误压根没被允许报告，那处理器也不会被触发。
• 最重要的一点：在自定义的处理器函数里，得把错误 throw 出来，不然它只是“处理了”错误，并没有真正“转成”异常。

看个例子：

set_error_handler(function($severity, $message, $file, $line) {    if (!(error_reporting() & $severity)) {        return; // 遵守当前错误报告级别    }    throw new ErrorException($message, 0, $severity, $file, $line);});try {    $x = $undefined_var; // 触发 E_NOTICE} catch (ErrorException $e) {    echo "Caught: " . $e->getMessage();}

error_reporting 和 display_errors 到底管什么？

这两个配置经常被一起关闭，但它们的作用完全不同，是两个独立的开关。

error_reporting 决定的是“哪些错误会被生成”，它是一个生产级别的开关。而 display_errors 决定的是“生成的错误是否直接输出到页面上”，它是一个展示级别的开关。

在生产环境下的典型配置是这样的：

• error_reporting(E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED)：记录所有错误，但忽略那些已弃用的提示，避免日志被无效信息淹没。
• display_errors = Off：这是必须的，防止敏感路径、变量值等泄露到前端，造成安全隐患。
• log_errors = On：确保错误被写入 error_log 文件或系统日志，方便事后排查。

有一点特别值得警惕：error_reporting(0) 不等于“没有错误发生”，而是“不生成任何错误事件”。这意味着连 set_error_handler 都收不到任何通知，所以调试时千万不要这么干，否则问题会像幽灵一样难以追踪。

致命错误（Fatal error）真的无解吗？

对于绝大多数 Fatal error（比如 Call to undefined function、Class not found），确实是无解的。它们无法被 try...catch 捕获，甚至连错误处理器都无能为力，因为 Zend 引擎已经决定要中止脚本了。

唯一能做的“事后补救”方式，就是注册 register_shutdown_function()，并在回调函数里通过 error_get_last() 来检查是否发生了致命错误：

register_shutdown_function(function() {    $error = error_get_last();    if ($error && in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])) {        // 记录日志、发告警、返回友好提示页        error_log("Fatal: " . $error['message'] . " in " . $error['file'] . ":" . $error['line']);        http_response_code(500);        echo "Service una vailable";    }});

但需要清醒地认识到，这只是一个“兜底”机制，它的作用仅限于事后的记录和友好提示，无法恢复脚本的执行。所以，真正有效的手段，是在部署之前就通过静态分析工具（比如 phpstan）、单元测试、自动加载校验等手段，尽可能把这些致命错误扼杀在摇篮里——这才是治本之道。