PHP全局处理未捕获异常方法解析

本文深入剖析了PHP中全局异常与错误处理的完整机制，指出仅依赖set_exception_handler无法覆盖PHP 7+引入的Error类致命错误（如FatalError、ParseError），必须结合set_error_handler和register_shutdown_function构建多层兜底体系；同时强调在异常处理器中应避免任何高风险操作（如数据库连接、HTTP请求、依赖全局变量），仅使用安全可靠的日志写入方式，并针对CLI与Web（尤其是php-fpm）环境差异给出可落地的实践建议——帮你真正捕获每一个崩溃瞬间，告别“日志空白、悄无声息退出”的线上排查噩梦。

set_exception_handler 能捕获什么异常

它只捕获「未被 try/catch 拦截」的 Exception 和继承自它的异常（比如 RuntimeException），但对 Error（如 FatalError、ParseError）完全无效——PHP 7+ 的 Error 是独立类型，必须用 set_error_handler + set_exception_handler 配合，或直接上 register_shutdown_function 补漏。

常见错误现象：set_exception_handler 函数写了，但 PHP Fatal error 仍直接报错退出，日志里没记录——这就是因为它根本没触发该回调。

• 只管未捕获的 Exception，不管 Error
• 一旦在 handler 内部抛出新异常，会直接 fatal，无法二次捕获
• 不能在 handler 里调用 exit() 或 die() 后还指望继续执行后续逻辑

PHP 7+ 必须同时处理 Error 和 Exception

从 PHP 7 开始，致命错误（如调用不存在的方法、内存耗尽）都转为 Error 对象，和 Exception 平级。只靠 set_exception_handler 等于漏掉一半崩溃场景。

正确做法是用 set_error_handler 捕获 E_ERROR 等级别错误，并配合 set_exception_handler；更稳妥的是统一收口到 register_shutdown_function，再用 error_get_last() 判断是否发生了未捕获的 Error 或异常终止。

• set_error_handler 默认不处理 E_ERROR、E_PARSE 等，需显式传入 E_ALL | E_STRICT
• set_exception_handler 和 set_error_handler 互不影响，可共存
• 在 CLI 模式下，register_shutdown_function 是兜底关键，Web 模式下也建议加上

示例兜底逻辑：

register_shutdown_function(function () {
    if ($error = error_get_last()) {
        if (in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])) {
            // 记录 fatal error
            error_log("FATAL: {$error['message']} in {$error['file']}:{$error['line']}");
        }
    }
});

全局 handler 里别做重依赖操作

异常发生时，程序状态已不可信：DB 连接可能断了、文件句柄可能损坏、内存可能即将耗尽。此时在 handler 里试图连数据库写日志、发 HTTP 请求、加载 Composer 类，极易引发二次崩溃或死锁。

真正安全的操作只有：写文件（用 fopen(..., 'a') + fwrite）、调用 syslog、输出到 STDERR，或极简的 JSON 日志写入。

• 避免在 handler 中使用 new PDO()、file_get_contents()、curl_init()
• 不要依赖 $_SERVER 或 $_REQUEST，它们在某些 SAPI（如 php-fpm 子进程崩溃）下可能为空或失效
• 日志路径务必用绝对路径，相对路径容易因工作目录变化导致写入失败

CLI 和 Web 环境的行为差异

CLI 脚本中，set_exception_handler 失效后进程直接退出，register_shutdown_function 是唯一可靠出口；而 Web 环境（如 Apache/mod_php 或 php-fpm）中，handler 执行完通常还能返回 HTTP 响应，但 fpm 子进程可能被标记为“异常退出”，影响平滑重启。

一个常被忽略的点：php-fpm 配置中的 request_terminate_timeout 触发时，不会走任何 PHP 层 handler，而是由 fpm 主进程直接 kill 子进程——这种超时崩溃，只能靠外部监控或慢日志（slowlog）发现。

• CLI 下建议始终启用 register_shutdown_function + error_get_last()
• Web 下注意检查 fpm 的 slowlog 和 access.log，别只盯着 PHP handler 日志
• 所有 handler 函数必须声明为 static 或全局函数，闭包在某些旧版本 fpm 下可能失效

最麻烦的不是写 handler，而是确认它真正在所有崩溃路径下都被执行到了——尤其是那些你以为“不可能发生”的 ParseError 或 OOM 场景。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~