php异常捕获最核心路径是try-catch-finally：try包裹可能出错代码，catch按子类到父类顺序捕获exception及其子类异常，finally确保资源清理必执行；它不捕获致命错误、警告或通知，仅处理throw抛出的throwable对象。
try 块里写可能出错的代码，catch 捕获对应异常类型，finally 保证清理逻辑必执行——这是 PHP 异常捕获最核心、最不可绕开的路径。其他方式（比如 set_error_handler）处理的是错误（E_WARNING 等），不是异常；想真正“捕获” throw 出来的对象，必须用 try-catch。
为什么 catch 不生效？常见匹配失败原因
最常见的假象是“写了 catch 却没进”，其实根本没抛出异常，或者抛的不是 Exception 子类。
-
file_get_contents("missing.txt")默认只触发E_WARNING，不抛异常——得配合@抑制再手动throw，或启用stream_context_set_default(['http' => ['ignore_errors' => true]])后自己判断返回值 -
mysql_connect()（已废弃）这类函数返回false，不是抛异常；PDO 模式下才默认抛PDOException - 自定义异常类没继承
Exception，比如class MyError {}，那catch (Exception $e)完全捕不到 - 子类异常写在父类后面：先写
catch (Exception $e)，再写catch (ValidationException $e)，后者永远进不去
catch 多个类型时的顺序和兼容性
PHP 7+ 支持多类型 catch，但语法限制严格，不能混用旧写法。
- 正确写法（PHP 7.1+）：
catch (ValidationException | DatabaseException $e)，两个类必须都继承自同一父类（如Exception） - PHP 7.0 及更早：只能分开写多个
catch块，且子类必须在前，比如FileNotFoundException在Exception之前 - 注意
Throwable是 PHP 7 引入的顶层接口，Exception和Error（如FatalError）都实现它；若想兜底捕获所有，用catch (Throwable $t)，但别在生产环境裸露$t->getTraceAsString()
finally 执行时机与资源释放陷阱
finally 确实“总会执行”，但有两个关键细节常被忽略：
- 如果
try或catch中调用了exit()或die()，finally不会执行——这点和 Java 不同 - 变量作用域问题：
$fp = fopen(...)在try里声明，finally里直接用fclose($fp)会报Undefined variable，得提前声明$fp = null或用isset($fp)判断 - 数据库事务场景下，
finally不能替代rollback()—— 如果try里已commit()，finally再关连接没问题；但如果中途失败，该回滚的必须在catch里做，finally只负责关连接
全局异常处理器 set_exception_handler 的真实定位
set_exception_handler() 不是“替代 try-catch 的捷径”，而是最后一道防线。
- 它只捕获**未被任何
catch拦截**的异常，一旦你在某层try里漏写了catch，它才起作用 - 函数内不能
return或echo响应内容——它运行时脚本已处于“异常退出前一刻”，输出可能被缓冲区截断，建议只做error_log()和http_response_code(500) - 无法恢复执行：这个回调执行完，脚本就终止了，不像
catch还能继续往下走 - CLI 模式下它有效，但 Web SAPI（如 Apache mod_php）中，若同时启用了
display_errors=On，错误仍可能暴露给用户，务必配ini_set('display_errors', '0')
try 包业务逻辑、精准 catch 特定异常类、finally 关资源；全局处理器只做日志兜底。最容易翻车的，是把 finally 当成万能收尾，却忘了它不处理业务回滚，也拦不住 exit()。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
