在业务逻辑较重的系统里，我们经常把一部分校验规则下沉到数据库触发器中执行，比如禁止删除有未结订单的客户、限制库存不能为负数等。触发器在校验失败时抛出错误，PHP端收到的大多是一句笼统的提示，排查起来非常费劲。其实MySQL从5.5版本开始就支持SIGNAL语法，允许触发器主动抛出携带自定义SQLSTATE码的异常，而PHP的PDO扩展会把完整的错误信息封装进PDOException对象。只要掌握了这两端的配合方式，就能实现按SQLState精确捕获和分类处理。
先在触发器里定义好自定义SQLSTATE
想在PHP端区分不同的触发器错误，第一步是让数据库端把错误的“身份”标识清楚。MySQL的SIGNAL语句专门干这件事，它允许在存储过程和触发器中主动抛出一个异常，并携带一个五位的SQLSTATE码以及自定义的错误消息。
按照约定，以45开头的SQLSTATE码保留给开发者自定义使用，例如45001到45099都可以自由分配给不同的业务规则。下面这个触发器示例演示了如何在删除客户前检查是否存在未结订单：
DELIMITER $$
CREATE TRIGGER trg_customer_before_delete
BEFORE DELETE ON customers
FOR EACH ROW
BEGIN
-- 检查该客户是否还有未完成的订单
IF EXISTS (SELECT 1 FROM orders WHERE customer_id = OLD.id AND status IN ('pending', 'shipped')) THEN
SIGNAL SQLSTATE '45001'
SET MESSAGE_TEXT = '该客户存在未结订单，禁止删除',
MYSQL_ERRNO = 1642;
END IF;
END$$
DELIMITER ;
这里的SQLSTATE '45001'就是我们自定义的业务错误码，MESSAGE_TEXT是返回给客户端的错误描述。当PHP通过PDO执行DELETE语句时，这条错误会以异常的形式抛出来，SQLSTATE码就藏在异常对象内部。
可以给不同的业务规则分配不同的码，比如45001表示存在未结订单、45002表示库存不足、45003表示权限校验失败，这样在应用层就能做到一码一策，处理逻辑清晰不混乱。
用PDO解析异常中的SQLState信息
PDO抛出的PDOException继承自RuntimeException，它比普通异常多了一个errorInfo属性，这是一个三元素数组：第一个元素是SQLSTATE码字符串，第二个元素是驱动特定的错误码，第三个元素是驱动特定的错误消息。需要注意的是，Exception基类的getCode方法在PDO场景下返回的不一定是SQLSTATE，它可能是整数形式的驱动错误码，所以更稳妥的做法是读取errorInfo[0]。
下面是一个基础的捕获示例：
<?php
try {
$pdo = new PDO('mysql:host=127.0.0.1;dbname=shop;charset=utf8mb4', 'root', 'secret', [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false,
]);
$stmt = $pdo->prepare('DELETE FROM customers WHERE id = ?');
$stmt->execute([42]);
} catch (PDOException $e) {
$sqlState = $e->errorInfo[0] ?? '';
if ($sqlState === '45001') {
echo '删除被拒绝：' . $e->errorInfo[2];
// 这里可以执行提示用户、记录日志等逻辑
} elseif ($sqlState === '40001') {
echo '检测到死锁，请重试';
} else {
// 其他未知错误，继续向上抛出
throw $e;
}
}
这段代码有几个关键点值得注意。首先，必须把PDO::ATTR_ERRMODE设置为PDO::ERRMODE_EXCEPTION，否则PDO不会抛异常，只会静默返回false，错误信息只能靠errorCode和errorInfo方法手动查询，写起来既啰嗦又容易遗漏。其次，一定要关闭模拟预处理（模拟预处理在某些驱动版本下会让错误信息延迟暴露）。最后，未知的SQLState不要吞掉，原样重新抛出让上层统一兜底，这是异常处理的基本纪律。
封装一个业务异常翻译层让代码更优雅
直接在业务代码里写一堆if-else判断SQLState，时间一长会散落得到处都是。更优雅的做法是封装一个专门的异常翻译类，把数据库层的错误码统一映射成应用层的领域异常，业务代码只需要catch自己关心的异常类型即可。
<?php
// 领域异常基类和具体异常
class BusinessRuleException extends RuntimeException {}
class PendingOrderException extends BusinessRuleException {}
class InsufficientStockException extends BusinessRuleException {}
class SqlStateTranslator
{
// SQLState到领域异常类名的映射表
private const MAP = [
'45001' => PendingOrderException::class,
'45002' => InsufficientStockException::class,
];
public static function toDomainException(PDOException $e): RuntimeException
{
$sqlState = $e->errorInfo[0] ?? '';
$message = $e->errorInfo[2] ?? $e->getMessage();
if (isset(self::MAP[$sqlState])) {
return new self::MAP[$sqlState]($message, 0, $e);
}
return $e; // 未识别的异常原样返回
}
}
// 使用示例
try {
$stmt = $pdo->prepare('DELETE FROM customers WHERE id = ?');
$stmt->execute([42]);
} catch (PDOException $e) {
throw SqlStateTranslator::toDomainException($e);
}
经过这层翻译，调用方的代码变得非常干净：catch PendingOrderException就处理未结订单的场景，catch InsufficientStockException就走库存不足的分支，完全不用关心底层是MySQL还是别的数据库，SQLState码也不会泄漏到业务层。这种“翻译层”思路在分层架构中非常实用，也让单元测试时mock数据库行为变得更加简单。
映射表建议用独立的配置数组维护，新增业务规则时只需在触发器里定义新码、在映射表里加一行，代码零改动扩展。这比在几十个文件里搜索硬编码的错误字符串要省心得多。
事务场景下的回滚与重试注意事项
触发器抛出错误还有一个容易踩坑的地方：事务。当DELETE或UPDATE在事务中执行且触发器SIGNAL了错误，MySQL会自动回滚这条语句本身，但整个事务并不会自动回滚（InnoDB下SIGNAL默认不会终止整个事务）。这意味着如果不在PHP端处理，后续语句可能继续在一个“半成品”状态下执行，造成数据不一致。
正确的做法是在catch块里显式调用rollBack，或者根据业务决定是否重试：
<?php
$pdo->beginTransaction();
try {
$pdo->exec('UPDATE stock SET qty = qty - 5 WHERE sku = 1001');
$pdo->exec('DELETE FROM customers WHERE id = 42');
$pdo->commit();
} catch (PDOException $e) {
$pdo->rollBack(); // 确保触发器错误不会留下半途数据
if (($e->errorInfo[0] ?? '') === '40001') {
// 死锁或锁等待超时，可以安全重试
return retryOperation();
}
throw SqlStateTranslator::toDomainException($e);
}
另外提醒一点：不要把ROLLBACK语句本身写进触发器里，MySQL的触发器内不允许包含隐式或显式提交事务的语句，回滚控制权应该交给应用层。还有，捕获异常后千万不要既回滚又当作“处理完成”继续往下走，这种静默吞错的方式是线上事故的常见源头。
常见问题与调试技巧
实际开发中经常会遇到“明明触发器SIGNAL了，PHP端却拿不到自定义码”的情况，多半是以下几个原因：一是用的是mysqli扩展而没开异常模式，mysqli默认返回错误码而不是抛异常，需要调用mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT)开启；二是 errorInfo数组取错了下标，SQLSTATE固定在索引0的位置；三是SQLSTATE码写成了以00、01或02开头的值，这类码分别代表成功、警告和数据不存在，不会触发异常。
调试时可以先用MySQL命令行客户端直接执行触发语句，确认SIGNAL确实生效、错误码符合预期，再去检查PHP端的捕获逻辑。两端分开验证能快速定位问题出在数据库还是应用层，比闷头改PHP代码效率高得多。
总结一下，优雅处理触发器异常的核心思路是：数据库端用SIGNAL为每条业务规则分配唯一SQLState，PHP端通过PDO异常的errorInfo精确识别，再用一层翻译器把技术错误转成领域异常，最后在事务边界上保证回滚干净利落。这套组合拳落地之后，数据库层的校验错误就从“令人头疼的字符串”变成了结构化、可编程的信号流，代码的可读性和可维护性都会上一个台阶。
PHP数据库异常处理SQLState触发器异常捕获修改时间：2026-09-07 14:26:52