php中不能直接用exception类做业务异常区分，因为所有业务异常混在同一个exception类型里，上层catch时无法精准识别是参数错误、数据库超时还是支付失败——只能靠$e->getmessage()字符串匹配，脆弱且易错。
PHP中为什么不能直接用Exception类做业务异常区分
因为所有业务异常混在同一个Exception类型里，上层catch时无法精准识别是参数错误、数据库超时还是支付失败——只能靠$e->getMessage()字符串匹配，脆弱且易错。
实操建议：
- 为每类业务场景定义独立的自定义异常类，如
InvalidOrderException、PaymentTimeoutException - 所有自定义类必须继承
Exception（或RuntimeException等标准子类），否则catch (Exception $e)捕获不到 - 不要在自定义类里重写
__construct()却忘记调用parent::__construct()，否则$e->getMessage()为空
如何让自定义Exception携带结构化上下文信息
原生Exception只支持$message、$code、$previous三个参数，但业务中常需记录订单ID、用户IP、请求参数等。硬塞进$message会导致解析困难。
实操建议：
- 在自定义类中添加公共属性，如
public $orderId;、public $requestParams; - 构造函数里接收并赋值，同时仍调用
parent::__construct($message, $code, $previous) - 重写
__toString()方法，把结构化字段格式化输出，方便日志记录
示例：
class InvalidOrderException extends Exception
{
public $orderId;
public function __construct($message, $orderId, $code = 0, Throwable $previous = null)
{
$this->orderId = $orderId;
parent::__construct($message, $code, $previous);
}
public function __toString()
{
return sprintf(
"%s: [%s] %s (OrderID: %s)\n",
__CLASS__,
$this->code,
$this->message,
$this->orderId
);
}
}
在Laravel或Slim等框架中如何统一处理自定义Exception
框架通常有全局异常处理器（如Laravel的App\Exceptions\Handler），但默认只按Exception类型分发。若未显式注册自定义类，它们会被降级为Exception兜底处理，丢失语义。
实操建议：
- Laravel中，在
register()方法里用$this->renderable()或$this->reportable()显式声明处理逻辑 - Slim v4需在
addErrorMiddleware()后，通过setErrorHandler()绑定对应异常类的处理器 - 避免在处理器里直接
echo或die，应统一返回JSON响应，并设置正确HTTP状态码（如400对应参数异常，503对应服务不可用）
自定义Exception类命名和存放位置的实际约束
PHP本身不限制命名，但PSR-4自动加载和IDE跳转依赖文件路径与命名严格匹配。常见错误是类名用了下划线（如Invalid_Order_Exception）或放在非命名空间对应目录。
实操建议：
- 类名用PascalCase，如
InsufficientBalanceException，文件名与之完全一致（InsufficientBalanceException.php） - 放在
src/Exceptions/目录下，并确保该路径已注册到composer.json的"autoload": {"psr-4": {...}}中 - 如果项目未启用自动加载，必须手动
require_once，否则抛出Class 'xxx' not found错误
真正容易被忽略的是：自定义异常类一旦被throw但未被捕获，会触发set_exception_handler()；而这个全局处理器若没适配你的新类，就会导致错误信息不完整或日志缺失。别只测try/catch分支，漏掉未捕获场景。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
