php中捕获报错主要通过try-catch结构处理可预见的异常，并结合set_exception_handler和set_error_handler应对未捕获异常及php错误。1. try-catch用于捕获开发者主动抛出或外部调用引发的exception，支持多层级catch匹配不同异常类型；2. php 7引入throwable统一error与exception，使部分错误如typeerror也可被捕获；3. set_exception_handler注册全局异常处理器，捕获未被try-catch处理的异常；4. set_error_handler拦截php运行时错误（如notice、warning），但无法处理致命错误；5. 实际项目应区分业务异常与系统异常，构建自定义异常体系，记录详细日志，避免吞噬异常，合理使用finally进行资源清理，提升应用健壮性。
说起PHP里怎么捕获报错，我们最先想到的，或者说最常用的，肯定就是try-catch这个结构了。它主要用来处理那些我们预料到可能发生的“异常”（Exception），让程序在遇到问题时不会直接崩溃，而是能按照我们设定的逻辑去应对。
在PHP里，要捕获一个可能抛出异常的代码块，最直接的方式就是用try-catch。我个人习惯是，只要是涉及到外部服务调用、文件操作、数据库查询这类“高风险”操作，都会不自觉地用try-catch包起来。
getMessage() . PHP_EOL;
// 这里可以记录日志、给用户友好的提示等
} catch (Exception $e) {
// 捕获所有其他类型的异常（通用捕获，通常放在最后）
echo "捕获到一个通用异常: " . $e->getMessage() . PHP_EOL;
} finally {
// 无论是否发生异常，finally 块的代码都会执行
echo "无论如何，这部分代码都会执行。" . PHP_EOL;
}
echo "程序继续执行到这里。" . PHP_EOL;
?>这套机制的核心在于，try块里的代码一旦抛出异常，后续的代码就不会再执行，而是立即跳转到第一个匹配的catch块。如果没有任何catch块能匹配到这个异常，那么这个异常就会成为一个未捕获异常，导致程序终止。
立即学习“PHP免费学习笔记（深入）”；
PHP中的“错误”和“异常”到底有何不同？
这可能是很多初学者，甚至一些有经验的开发者都会混淆的地方。简单来说，PHP 7 之前，我们通常说的“错误”是那些致命错误（Fatal Error）、警告（Warning）、通知（Notice）等，它们通常由PHP引擎自身在运行时检测到，比如调用了不存在的函数、语法错误等。这些错误很多时候是不能用try-catch直接捕获的，它们会中断脚本执行，或者只是发出警告。
而“异常”（Exception）则是一种面向对象的错误处理机制。它通常是我们开发者自己通过throw new Exception()来抛出的，或者由PHP内置的一些函数（如json_decode在某些情况下）抛出。异常是可以被try-catch结构捕获的。
PHP 7 引入了Throwable接口，它统一了Error和Exception。这意味着现在像TypeError、ParseError、ArithmeticError这些在PHP 7 之前可能导致脚本终止的“错误”，现在也实现了Throwable接口，理论上可以被catch (Throwable $e)捕获了。但即便如此，我们平时还是习惯把那些可预见的、通过throw语句产生的称为“异常”，而把那些由PHP引擎内部产生的、通常表示程序结构或环境问题的称为“错误”。理解这个区别很重要，因为它决定了你用什么方法去“抓”它们。
如何处理那些未被try-catch捕获的异常和致命错误？
光靠try-catch是远远不够的。在一个复杂的应用里，总会有你没预料到的异常，或者那些直接就是PHP引擎抛出的致命错误。这时候，我们就需要一个“兜底”的机制。PHP提供了两个非常重要的函数来做这件事：set_exception_handler()和set_error_handler()。
set_exception_handler()用于注册一个全局的未捕获异常处理器。任何没有被try-catch捕获的异常，最终都会被这个处理器捕获。这对于记录日志、向用户显示一个友好的错误页面、或者发送错误通知给开发者来说至关重要。
getFile() . " (行: " . $exception->getLine() . ")\n";
echo "消息: " . $exception->getMessage() . "\n";
// 实际应用中，这里应该写入日志文件，而不是直接输出
error_log("Uncaught Exception: " . $exception->getMessage() . " in " . $exception->getFile() . " on line " . $exception->getLine());
// 还可以发送邮件通知开发者
// mail('dev@example.com', 'Uncaught Exception', $exception->getMessage());
exit(1); // 终止脚本执行
});
// 故意抛出一个未捕获的异常
// 这段代码没有被try-catch包围
throw new RuntimeException("这是一个故意制造的未捕获运行时异常！");
echo "这行代码永远不会执行到，因为上面已经抛出了异常并被处理器捕获并终止了脚本。";
?>set_error_handler()则用来处理那些PHP的运行时错误（如Warning、Notice等）。通过它，你可以将PHP的内置错误报告机制“劫持”过来，让它们不再直接输出到屏幕上，而是按照你的逻辑去处理，比如转换为异常，或者记录到日志。
通过这两种机制，你几乎可以捕获并处理PHP脚本运行中遇到的大部分问题，从而提升应用的健壮性。
实际项目中，异常处理的“最佳实践”到底长什么样？
我个人觉得，在实际项目中，异常处理不仅仅是写几个try-catch那么简单，它更像是一种架构设计和开发习惯。
-
区分业务异常和系统异常：
-
业务异常：比如用户提交表单数据不合法（密码太短、用户名已存在），或者订单状态不允许操作。这类异常通常是可预见的，而且应该给用户一个明确的反馈。我们通常会定义自己的业务异常类，比如
UserInvalidInputException。 - 系统异常：数据库连接失败、第三方API超时、文件读写权限问题。这类异常通常表示系统底层出了问题，用户无法解决，需要开发者介入。这类异常通常不需要直接暴露给用户，而是记录日志，并显示一个友好的“系统繁忙”页面。
-
业务异常：比如用户提交表单数据不合法（密码太短、用户名已存在），或者订单状态不允许操作。这类异常通常是可预见的，而且应该给用户一个明确的反馈。我们通常会定义自己的业务异常类，比如
-
构建自定义异常体系： 继承PHP内置的
Exception类，创建一套符合你项目业务逻辑的异常类。这不仅能让你的catch块更精确地捕获特定类型的错误，也能让代码更具可读性。比如：class DatabaseConnectionException extends Exception {} class UserNotFoundException extends Exception {} class PaymentFailedException extends Exception {}这样在
catch的时候，你可以根据异常类型做不同的处理。 日志先行： 任何捕获到的异常，尤其是系统异常，第一时间都应该被记录到日志系统里（比如Monolog）。日志应该包含详细的信息：异常消息、文件、行号、调用栈、请求上下文（URL、IP、POST数据等）。这对于后续的排查和定位问题是至关重要的。
不要“吞噬”异常： 最糟糕的异常处理方式就是捕获了异常，然后什么都不做，或者只打印一个简单的消息。这会让你失去发现问题的机会。如果捕获了异常，要么处理它（比如重试、回滚），要么重新抛出一个更高级别的、更具业务含义的异常，或者至少要记录日志。
全局错误和异常处理器是“最后一道防线”： 就像前面提到的
set_exception_handler和set_error_handler，它们是你的应用在最糟糕情况下还能保持体面、并留下线索的关键。确保它们能够捕获所有未处理的问题，并进行适当的日志记录和通知。避免在循环中频繁捕获异常： 在紧密的循环中进行
try-catch会带来额外的性能开销。如果可能，尽量在循环外部进行批量操作，并在批量操作失败时捕获异常，或者在循环内部的每个迭代中，通过条件判断来避免可能抛出异常的操作，而不是直接依赖try-catch。合理使用
finally块：finally块非常适合做一些清理工作，比如关闭数据库连接、释放文件锁、清除临时文件等，无论try块中是否发生异常，finally块都能保证这些操作被执行。
异常处理不是简单的代码堆砌，它是构建健壮、可维护应用程序的关键环节。它要求我们不仅要考虑“代码怎么跑”，还要考虑“代码跑飞了怎么办”，并且要能留下足够的线索，方便我们找到它为什么跑飞了。
