php怎样全局处理未捕获异常_php全局处理未捕获异常方法【机制】

set_exception_handler仅捕获未被try/catch拦截的exception及其子类，对Error（如fatalerror、parseerror）完全无效；php 7+需配合set_error_handler和register_shutdown_function兜底处理。

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 或异常终止。

立即学习“PHP免费学习笔记（深入）”；

• 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 场景。