PHP如何捕获致命错误？

PHP中的致命错误（如解析错误、未定义函数调用、核心编译失败等）无法通过常规的try/catch捕获，这是由Zend引擎底层执行机制决定的硬性限制；唯一可靠且通用的捕获方式是在脚本最开始注册register_shutdown_function，并结合error_get_last()进行轻量级日志记录与告警——但需谨记它仅适用于多数运行时致命错误，对扩展崩溃、OOM杀进程等极端情况无能为力，因此生产环境还需配合外部监控与严谨的日志配置，才能真正筑牢错误防御的最后一道防线。

PHP 无法用 try/catch 捕获 fatal error

致命错误（如 ParseError、FatalError、TypeError 在某些版本中）在 PHP 中默认不进入异常处理流程，try/catch 完全无效。这不是写法问题，是底层机制限制——它们发生在 Zend 引擎执行阶段之前或中途崩溃，根本没机会走到用户代码的异常处理器里。

常见现象包括：

• 调用未定义函数（Call to undefined function xxx()）后脚本直接终止，catch (Throwable $e) 不触发
• require 一个不存在的文件，报 Fatal error: Uncaught Error: Failed opening required...，后续代码不执行
• 类继承破坏 LSP（如 declare(strict_types=1) 下协变返回类型不匹配），直接 fatal，不抛 Error

register_shutdown_function 是唯一可靠入口

PHP 提供 register_shutdown_function() 作为脚本终止前最后可运行的钩子，它能捕获所有终止原因：正常结束、exit()、fatal error、甚至 segfault（但此时可能无法安全操作内存）。关键在于配合 error_get_last() 判断是否真发生了致命错误。

实操建议：

• 必须在脚本最开始注册，越早越好（比如入口文件第一行），否则中间 require 的 fatal 可能错过
• 不要在 shutdown 函数里做复杂逻辑（如数据库写入、远程请求），因资源可能已释放或超时
• 只检查 error_get_last() 的 type 字段是否属于致命类别：E_ERROR、E_PARSE、E_CORE_ERROR、E_COMPILE_ERROR、E_USER_ERROR
• 注意：PHP 7+ 的 Error 类型（如 TypeError、ParseError）在某些 fatal 场景下仍不会触发 shutdown，但绝大多数运行时 fatal 都能捕获到

示例片段：

register_shutdown_function(function () {
    if ($error = error_get_last()) {
        if (in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR])) {
            // 记录日志、发告警、清理临时文件
            error_log("FATAL: {$error['message']} in {$error['file']}:{$error['line']}");
        }
    }
});

set_error_handler 对 fatal error 无效，但能补位部分场景

set_error_handler() 只接管 E_WARNING、E_NOTICE 等非终止性错误，对 fatal 完全无感。但它能帮你提前拦截一些“准致命”行为，比如：

• 用 @ 抑制警告后未检查结果，导致后续 null 解引用 —— 其实可在 error handler 里记录并强制转成异常
• 自定义 E_USER_ERROR（通过 trigger_error(..., E_USER_ERROR)）会被 set_error_handler 捕获，且可选择 throw Exception 或 Error，从而被外层 try/catch 拦住
• PHP 8.0+ 的 match 表达式漏掉分支会报 UnhandledMatchError（属 Error），它虽是 fatal 级别，但能被 catch (Error $e) 捕获 —— 这是少数可用 try/catch 的例外

开发期 vs 生产环境的处理差异

本地开发时开启 display_errors = On 和 error_reporting = -1 能快速暴露问题，但生产环境必须关掉 display_errors，否则泄露路径、变量名等敏感信息。此时 log_errors = On + 正确配置 error_log 路径才是关键。

容易忽略的点：

• error_log 配置为 syslog 时，需确认系统 syslog 服务正常，否则错误静默丢失
• Docker 容器中若未挂载日志目录或权限不足，error_log 文件可能写入失败，shutdown 函数里也拿不到 error_get_last()
• CLI 模式下 register_shutdown_function() 依然有效，但 Web SAPI（如 FPM）中若 worker 被强制 kill（如 OOM killer），shutdown 可能不执行

真正难处理的是那些连 shutdown 都来不及跑的情况：PHP 扩展 segfault、内核级内存耗尽、fpm master 进程直接杀 worker。这类问题得靠外部监控（如 systemd 日志、supervisor 状态、APM 工具）兜底。

以上就是《PHP如何捕获致命错误？》的详细内容，更多关于的资料请关注golang学习网公众号！