PHP 业务异常和系统异常

wen PHP项目 2026-08-10 2

PHP异常处理深度剖析：业务异常与系统异常的边界、捕获与最佳实践

目录导读

引言：异常不是Bug，而是程序的语言
核心概念：业务异常（可预期）VS 系统异常（不可控）
实操指南：如何用代码优雅区分两类异常
高级策略：全局异常处理器与日志分级
常见问答：解决你关于异常的5个疑问
建立你的异常“红绿灯”机制

引言：异常不是Bug，而是程序的语言

在PHP开发中，异常（Exception）常被误解为“错误”，但优秀的架构师会告诉你：异常是业务规则与系统边界在代码层面的显性表达，如果我们不区分“用户余额不足”和“数据库连接超时”，所有异常都堆在同一个catch块里，代码将迅速腐烂，本文将基于PHP 7+及现代框架（Laravel/Symfony）的实践,深度拆解这两类异常的管理哲学。

PHP 业务异常和系统异常

核心概念：业务异常（可预期）VS 系统异常（不可控）

维度	业务异常 (Business Exception)	系统异常 (System Exception)
触发源	业务规则冲突（如库存不足、参数校验失败）	环境/基础设施故障（如Redis连接超时、文件无权限）
可预测性	高（由输入数据决定）	低（随机、偶发）
对用户	需友好提示（“您的优惠券已过期”）	需隐晦记录（“系统繁忙，请稍后”）
处理方式	捕获后恢复流程（返回错误码/重定向）	捕获后降级或重试（记录日志并告警）
异常类	自定义`BusinessException`	原生`RuntimeException` / `ErrorException`

关键区别：业务异常是逻辑分支（需要返回给用户看），系统异常是故障信号（需要发送给运维看）。

实操指南：如何用代码优雅区分两类异常

第一步：定义异常基类

// 业务异常基类
class BusinessException extends \RuntimeException {
    protected $errorCode;
    public function __construct($message, $code, $errorCode) {
        parent::__construct($message, $code);
        $this->errorCode = $errorCode;
    }
    // 获取业务错误码（用于前端翻译）
    public function getErrorCode() { return $this->errorCode; }
}
// 系统异常推荐直接使用原生类或自定义标记接口
interface SystemExceptionInterface {}

第二步：在Service层定向抛出

// 业务层：抛出业务异常（带提示信息）
public function withdraw($amount) {
    if ($amount > $this->balance) {
        throw new BusinessException('余额不足', 400, 'BALANCE_NOT_ENOUGH');
    }
    // 系统操作（如调用支付网关）
    try {
        $this->gateway->charge($amount);
    } catch (\Exception $e) {
        // 关键：包装为系统异常，丢失敏感SQL，保留错误上下文
        throw new SystemException('支付网关调用失败', 500, $e);
    }
}

第三步：入口文件分层捕获

在index.php或中间件中，采用双catch块或instanceof判断。

try {
    $response = $kernel->handle($request);
} catch (BusinessException $e) {
    // 返回200状态码 + JSON业务错误码（前端可读）
    return json_encode(['code' => $e->getErrorCode(), 'msg' => $e->getMessage()]);
} catch (\Throwable $e) { // 捕获所有系统异常/错误
    // 记录完整堆栈到error_log
    Log::error($e->getTraceAsString(), ['uri' => $request->getUri()]);
    // 返回500 + 通用文案
    return response('System Busy', 500);
}

高级策略：全局异常处理器与日志分级

使用框架的Rendering：在Laravel的Handler中，对BusinessException直接return response()->json(...)，对SystemException先上报到Sentry（监控系统）,再返回兜底500。
日志分级：业务异常打印为INFO级别（记录用户行为），系统异常打印为ERROR级别（触发告警）。
重试机制：针对系统异常中的ConnectionException，使用指数退避策略重试3次；业务异常绝不重试（避免重复扣款）。

常见问答：解决你关于异常的5个疑问

问题	解决方案
Q1：为什么业务异常不能继承`\Exception`?	因为`Exception`是基类，用`RuntimeException`作为子类基类能更好区分“运行时错误”，建议业务类继承`\RuntimeException`，系统类继承原生`\Exception`或`\ErrorException`。
Q2：如何在Controller中找出是哪类异常？	使用`instanceof`操作符，顺序很重要：先判断`BusinessException`，再判断`SystemExceptionInterface`。
Q3：前端如何识别这两类HTTP状态码？	业务异常返回`200` + 自定义`code`字段；系统异常返回`500`或`503`，前端只看HTTP状态码即可，若遇500直接弹系统错误。
Q4：业务异常是否应该包含SQL错误？	绝对不要，业务异常信息必须对用户友好且不包含内部表名/字段。
Q5：性能影响大吗？	PHP异常抛出略慢于`if-else`，但不要为了性能放弃清晰度。可利用`finally`或`try-catch`块懒加载资源来弥补。

建立你的异常“红绿灯”机制

绿灯（业务异常）：让用户知道下一步怎么做（改参数、转人工）。
红灯（系统异常）：让开发者知道系统哪里坏了（发告警邮件、监控大屏）。

最终忠告：永远不要在catch块里echo出异常，而是转换并上抛，在微服务架构中，请用RPC框架的ErrorCode传递业务异常，用熔断器解决系统异常，当你能清晰回答“这个异常该给谁看？”时,你的PHP代码已经具备生产级水准。

关注点：本文已综合PHP官方文档、Laravel异常处理手册及Stack Overflow高赞问答，结合搜索引擎高频关键词（“PHP异常类型”、“业务异常处理Laravel”）进行去重重组,确保内容对SEO友好。