PHP异常捕获规范有哪些必须注意的关键事项

从事 PHP 开发多年，最令人头疼的往往不是复杂的业务逻辑，而是异常处理代码如同“摸奖”——该捕获的异常漏掉了，该记录的日志缺失了，一旦线上出现问题，排查时毫无头绪。本文将深入剖析 PHP 异常捕获中的常见陷阱与必须遵守的规范，帮助开发者写出更健壮的代码。

先澄清一个非常普遍的误区：很多人误以为 try-catch 能够捕获所有运行时错误。实际上，PHP 的异常体系仅对 Exception 及其子类 生效。而 Warning、Notice 甚至 Fatal Error 这类错误（属于 Error 类体系）虽然与 Exception 都实现了 Throwable 接口，但处理逻辑截然不同——catch 块根本不会处理它们。

必须分清：哪些能 catch，哪些不能

能被 try-catch 捕获的，只有显式抛出的异常对象：

• 手动 throw new Exception("...") 或自定义异常类实例
• 系统级异常：比如 PDOException（数据库操作失败）、InvalidArgumentException（参数非法），以及 PHP 7.3+ 启用 JSON_THROW_ON_ERROR 时抛出的 JsonException

以下情形，try-catch 完全无能为力：

• file_get_contents("missing.txt") —— 触发的是 E_WARNING，并非异常，catch 无法接收
• 调用未定义函数 foo() —— 直接引发 Fatal error: Uncaught Error，脚本立即终止
• 语法错误、内存耗尽、类未找到（Class not found）—— 统统属于 Fatal Error，catch 块根本不会执行

catch 块顺序与类型必须严谨

多个 catch 的排列顺序有一条硬性规则：子类在前，父类在后。一旦将父类放在前面，后面的子类 catch 就永远没有机会执行：

• ✅ 正确：catch (PDOException $e) → catch (RuntimeException $e) → catch (Exception $e)
• ❌ 错误：把 Exception 放在最前面，后面所有子类 catch 全部失效，等于白写
• PHP 8+ 还支持单个 catch 捕获多类型：catch (PDOException | RuntimeException $e)，适合处理逻辑相同的场景，避免重复代码

finally 不是可选项，而是资源安全底线

finally 块的神奇之处在于：无论是否抛异常、是否被捕获，它都会执行。这是释放资源不可替代的机制：

• 文件句柄、数据库连接、临时锁、缓存标记……这些必须在 finally 中显式关闭或清理
• 别只依赖 catch 来处理——如果没异常，catch 不执行，资源就会泄漏，后果严重
• 特别注意：finally 中的 return 会覆盖 try 或 catch 中的返回值，除非刻意为之，否则慎用

空 catch 是危险信号，日志是最低要求

写 catch (Exception $e) { } 相当于主动把问题埋进土里——线上出了错连个响都听不到。至少要做到：

• 记录完整上下文：error_log($e->getTraceAsString(), 3, '/var/log/php/app.log');
• 生产环境禁止 echo $e->getMessage() 或直接输出堆栈，防止敏感路径/配置泄露
• 不要用异常做流程控制：比如用 throw 代替 if，这会让逻辑变得难以追踪，得不偿失