MySQL触发器异常不能仅靠try-catch包住，因PDO默认不抛异常，需显式启用ERRMODE_EXCEPTION；且SIGNAL抛出的SQLSTATE（如'45000'）可能被覆盖为HY000，须组合连接配置、SQLState校验与规范SIGNAL语句才能稳定捕获。
触发器异常为什么不能靠 try-catch 一层包住就完事
因为触发器内部抛出的错误（比如 SIGNAL SQLSTATE '45000' ）在 MySQL 层面会原样透传到 PHP 驱动，但 PDO 默认不主动抛异常——它可能静默返回 false，或只在 PDO::ERRMODE_EXCEPTION 开启后才转成 PDOException。更麻烦的是：即使开了异常模式，PDOException::$sqlstate 的值未必是你 SIGNAL 的那个，尤其当触发器里嵌套了其他语句、或 MySQL 版本低于 5.7.2 时，SQLState 可能被覆盖成通用错误码（如 HY000）。
如何稳定捕获自定义触发器异常（如 SQLSTATE '45000'）
关键不是“能不能 catch”，而是“怎么确认 caught 的确实是触发器抛的”。必须组合三要素：
- 连接时强制启用异常模式：
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION) - 执行后立即检查
$e->getSqlState()，而不是只看$e->getCode()（后者是驱动层错误码，不可靠） - 在触发器中用标准方式抛错：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'balance_insufficient';，避免用RESIGNAL或无SET的裸SIGNAL，否则 SQLState 可能丢失
示例片段：
try {
$pdo->exec("INSERT INTO transfers (from_id, to_id, amount) VALUES (1, 2, 1000)");
} catch (PDOException $e) {
if ($e->getSqlState() === '45000') {
// 真正的业务级触发器中断，可转为用户提示
throw new InsufficientBalanceException($e->getMessage());
}
throw $e; // 其他错误继续上抛
}
常见误判点：SQLState 是 'HY000' 或 '00000' 怎么办
这通常说明触发器没真正执行到 SIGNAL，或被更早的语法/权限错误拦截了。排查顺序如下：
立即学习“PHP免费学习笔记（深入）”；
- 确认触发器已启用：
SELECT name, is_disabled FROM sys.triggers WHERE parent_id = OBJECT_ID('transfers')（注意：MySQL 用information_schema.TRIGGERS，字段是STATUS） - 检查触发器定义里是否用了未声明的变量，或
SELECT无INTO导致运行时报错，这类错误优先于SIGNAL触发 - 验证 MySQL 版本是否支持该 SQLState：低于 5.5 不支持自定义
SIGNAL；5.5–5.6 仅支持'45000'；5.7+ 才支持任意 5 位自定义码 - 临时关闭触发器，手动执行触发器体内的逻辑，看是否报相同 SQLState —— 能快速定位是触发器本身问题，还是调用上下文干扰
生产环境必须加的兜底：日志里留痕 SQLState 和原始消息
别只记录 $e->getMessage()。触发器错误常带业务上下文（比如 “user_id=123, balance=50”），但默认会被 PDO 脱敏。必须手动拼接：
error_log(sprintf('[TRIGGER_ERR] SQLState=%s, Message="%s", SQL="%s"', $e->getSqlState(), $e->getMessage(), $lastExecutedSql), 3, '/var/log/php/db-trigger.log');
这里 $lastExecutedSql 需在 exec() 前保存（预处理语句则保存 $stmt->queryString + 绑定参数）。否则出问题时，你只能看到 “balance_insufficient”，却不知道是哪笔转账、哪个账户触发的——这个细节，90% 的线上系统都漏了。
