PHP try-catch无法捕获Fatal Error等致命错误，因它们不属于Exception体系；PHP 7+需catch Throwable才能捕获Error，但Parse Error等编译期错误仍不可捕获，须结合register_shutdown_function实现双保险兜底。
PHP try-catch 无法捕获致命错误（Fatal Error）
PHP 的 try-catch 只能捕获 Exception 和继承自它的异常（比如 RuntimeException），对 Fatal Error（如调用未定义函数、内存耗尽、语法错误）、Parse Error、TypeError（PHP 7+ 默认是 Error 类型，非 Exception）完全无效。这是最常被误以为“没起作用”的根本原因。
常见现象：call to undefined function xxx() 或 allowed memory size exhausted 直接终止脚本，catch (Exception $e) 完全不触发。
-
Error类型（PHP 7+）和Exception是平行继承关系，都继承自Throwable，所以必须显式 catchThrowable才能兜底 - PHP 5 中
Fatal Error根本不可捕获，只能靠register_shutdown_function()配合error_get_last()拾取 - 即使写了
catch (Throwable $e)，也无法捕获Parse Error（发生在编译阶段，脚本根本没执行到 try 块）
PHP 7+ 正确兜底：catch Throwable + shutdown handler 双保险
要真正覆盖大多数“未捕获错误”，得组合使用：
- 顶层
try-catch包裹主逻辑，且catch (Throwable $e)—— 捕获运行时Error和Exception -
register_shutdown_function()注册关机函数，在脚本异常终止（包括 Fatal）后检查error_get_last() - 注意：shutdown handler 里不能再抛出未捕获异常，否则会二次崩溃；建议只做日志记录或发送告警
示例关键结构：
立即学习“PHP免费学习笔记（深入）”；
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']);
// 可选：写入监控系统、发钉钉/邮件
}
}
});
try {
// 主业务逻辑
} catch (Throwable $e) {
error_log('THROWABLE: ' . $e->getMessage() . ' in ' . $e->getFile() . ':' . $e->getLine());
// 统一响应、清理资源等
}
哪些错误注定无法在 try-catch 中“拦截”并继续执行？
不是所有错误都能被“兜住后当没事发生”。有些错误一旦触发，PHP 进程已处于不可恢复状态：
-
E_PARSE（语法错误）：文件加载时即报错，try块甚至没机会解析 -
E_ERROR中的某些子类，如Allowed memory size exhausted：内存彻底耗尽，连日志写入都可能失败 -
Segmentation fault（扩展层崩溃）：PHP 进程直接被系统 kill，shutdown handler 都不一定能跑完 -
exit()/die()：主动终止，不触发任何异常机制
这类情况只能靠外部手段监控（如进程存活检查、慢日志、APM 工具），不能指望 PHP 内部代码“救回来”。
别把 set_error_handler 当成 try-catch 替代品
set_error_handler() 能捕获 E_WARNING、E_NOTICE 等错误，但它不会阻止错误继续发生，也不会让 try-catch 突然变灵光。它只是给你一个“看到警告”的机会。
- 它对
Fatal Error无效（PHP 会跳过 handler 直接终止） - 它不能把
E_WARNING“转成”Exception，除非你手动throw new Exception()—— 但那是在 warning 发生后额外抛异常，和原始错误无关 - 滥用
error_reporting(0)+set_error_handler掩盖问题，反而会让Undefined variable类错误悄悄引发逻辑错乱
真正需要兜底的，是明确知道某段代码可能抛出 Throwable（比如 JSON 解析、远程请求、反射调用），就用 try-catch (Throwable)；其他场景，优先修复根源，而不是堆砌防御性 handler。
