应使用 set_exception_handler() 注册全局异常处理器捕获未处理的 Exception，但需注意其不处理 Error 类错误，且不能替代业务层的 try...catch。
PHP 默认异常没被捕获，页面直接报错怎么办
PHP 的 Exception 如果没被 try...catch 捕获，会触发致命错误（Fatal error: Uncaught Exception...），导致脚本中断、白屏。这不是「没处理」，而是 PHP 根本没给你机会——它直接终止了。
解决思路很直接：用 set_exception_handler() 注册一个全局兜底处理器，所有未捕获的异常都会流到这儿。
- 必须在脚本早期注册，比如入口文件最开头，否则中间抛出的异常可能已漏掉
- 该函数只接管
Exception及其子类，不处理Error（如ParseError、TypeError），PHP 7+ 的Error需另配set_error_handler()或set_exception_handler()配合throw new ErrorException()转换 - 别在处理器里再抛异常，否则会二次崩溃，连日志都写不出
示例：
set_exception_handler(function ($e) {
error_log('[EXCEPTION] ' . $e->getMessage() . ' in ' . $e->getFile() . ':' . $e->getLine());
http_response_code(500);
echo '系统忙，请稍后再试';
});
自定义异常类怎么写才真正有用
直接 throw new Exception('xxx') 很省事，但问题在于：没法区分是数据库超时、还是用户输入非法、还是第三方 API 返回异常。统一用一个类，后续做监控、重试、降级都无从下手。
立即学习“PHP免费学习笔记（深入）”；
关键不是「能不能写」，而是「要不要分层」和「字段是否可扩展」。
- 继承
Exception即可，不用实现额外接口；PHP 自带的getMessage()、getCode()、getTraceAsString()全都能用 - 推荐按业务域建子类，比如
DatabaseException、ValidationException、PaymentException，而不是按严重程度（如WarningException）——后者语义模糊，且 PHP 不支持多继承，分类混乱 - 构造函数里别硬编码错误码，用常量或配置注入；
$code参数建议设为整数，方便前端或监控系统映射 HTTP 状态码（如 400/422/503）
示例：
class ValidationException extends Exception
{
public function __construct($message = '', int $code = 422, Throwable $previous = null)
{
parent::__construct($message, $code, $previous);
}
}
set_exception_handler 和 try...catch 冲突吗
不冲突，但有明确优先级：任何 try...catch 块内抛出的异常，只要被对应类型的 catch 捕获，就根本不会到达 set_exception_handler()。它是真正的「最后防线」。
容易踩的坑是误以为注册了全局处理器就不用写 try...catch 了——恰恰相反，核心逻辑（比如调用支付 SDK、写数据库）必须主动用 try...catch 处理可预期异常，否则你连重试、回滚、友好提示都做不到。
-
set_exception_handler()适合做三件事：记录全量异常堆栈、返回统一错误响应、触发告警（如发 Slack / 钉钉） - 它不适合做业务恢复，比如 catch 到
DatabaseException后自动切从库——这种逻辑必须写在try...catch里 - 如果用了框架（如 Laravel、Symfony），它们通常已封装好全局异常处理，此时再手动调
set_exception_handler()可能被覆盖，得查文档确认钩子时机
PHP 8.0+ 的 throw 表达式会影响异常捕获吗
不影响捕获逻辑，但会让异常来源更隐蔽。比如你在三元表达式里写 $user ?: throw new InvalidArgumentException('User required')，这个异常仍会被最近的 catch 或全局处理器捕获。
真正的问题是调试难度上升：堆栈里看不到明确的 throw 行号，IDE 也不好跳转，尤其嵌套深时，getTrace() 显示的是表达式所在行，而非实际执行点。
- 简单判断场景（如参数校验）可用，但别用在复杂业务分支里，比如
is_paid() ? process() : throw new PaymentPendingException() - 涉及资源清理（如
fopen()后必须fclose()）的场景，绝对不要用throw表达式替代完整语句块，否则finally或析构函数可能失效 - 团队协作时，建议禁用该语法——不是因为它错，而是它让「异常路径」从显性控制流变成了隐性表达式，新人容易漏看
try...catch 里对具体异常类型的识别和响应。堆栈最深那行 throw，往往才是问题真正的起点。 
