PHP PDO 事务异常时怎样保证回滚

PHP PDO 事务异常时，可靠的回滚写法不是在 catch 里无条件调用 rollBack()，而是先用 beginTransaction() 明确开启事务，再用 inTransaction() 判断当前连接是否仍有活动事务。这样既能撤销已经执行的写操作，也不会因为回滚动作本身抛出“没有活动事务”的异常，掩盖真正的问题。

官方地址：https://www.php.net/manual/zh/pdo.transactions.php

推荐的基本边界是：开启事务 → 执行全部写操作 → 统一提交；任意一步失败时，只对仍处于活动状态的事务回滚，最后把原始异常继续抛给上层。

先把异常模式和事务边界放在一起

PDO 默认的错误处理方式不一定会把执行失败转换为异常。若业务依赖 try...catch 走回滚路径，应在连接建立后设置 PDO::ATTR_ERRMODE 为 PDO::ERRMODE_EXCEPTION。事务也要通过 beginTransaction() 启动，不能只依靠某条 SQL 语句“看起来像”开启了事务。

 PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
]);

try {
    // 只有显式开启后，PDO 才知道后续修改属于哪个事务范围。
    $pdo->beginTransaction();

    $insert = $pdo->prepare(
        'INSERT INTO orders (user_id, amount) VALUES (:user_id, :amount)'
    );
    // 绑定参数让数据和 SQL 结构分离，也便于在异常时定位是哪次执行失败。
    $insert->execute(['user_id' => $userId, 'amount' => $amount]);

    $pdo->commit();
} catch (Throwable $error) {
    // 这里只展示边界判断，完整的安全回滚函数见下文。
    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }
    throw $error; // 保留原始异常和调用栈，让上层决定如何响应。
}
?>

上面代码的关键不是把所有数据库调用塞进一个大 try，而是让“事务已经开启”成为可判断状态。连接失败发生在 beginTransaction() 之前时，就不应该调用回滚；事务开启后某条写操作失败时，才进入回滚范围。

用 inTransaction 保护回滚动作

PDO::rollBack() 回滚的是当前由 beginTransaction() 发起的活动事务；没有活动事务时，调用它可能再次抛出 PDOException。因此，异常处理要先判断 inTransaction()，而不是把 rollBack() 当成无条件清理函数。

inTransaction()) {
        return;
    }

    try {
        // 只撤销当前 PDO 连接中尚未提交的事务改动。
        $pdo->rollBack();
    } catch (PDOException $rollbackError) {
        // 回滚失败不能替换原始异常；记录上下文后交给调用方处理。
        error_log('PDO rollback failed: ' . $rollbackError->getMessage());
        throw $rollbackError;
    }
}

try {
    $pdo->beginTransaction();
    $pdo->prepare('UPDATE inventory SET stock = stock - :count WHERE id = :id')
        ->execute(['count' => $count, 'id' => $itemId]);
    $pdo->commit();
} catch (Throwable $error) {
    // 判断事务状态后再处理，避免二次异常覆盖原始错误。
    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }
    throw $error;
}
?>

生产代码中可以把回滚和日志封装到统一函数，但不要为了“清理彻底”在 commit() 成功后再次回滚。提交成功后连接回到自动提交状态，后续回滚不再属于刚才那次业务操作。

让提交成为唯一成功出口

一个事务通常包含多条互相依赖的写操作。例如创建订单后还要扣减库存：只完成其中一条，会产生业务上无法接受的半成品。让 commit() 成为 try 块里最后一个成功出口，能够把“所有写入成功”与“任意一步失败”清晰分开。

beginTransaction();

    $createOrder = $pdo->prepare(
        'INSERT INTO orders (user_id, amount) VALUES (:user_id, :amount)'
    );
    $createOrder->execute(['user_id' => $userId, 'amount' => $amount]);

    $decreaseStock = $pdo->prepare(
        'UPDATE inventory SET stock = stock - :quantity WHERE id = :id AND stock >= :quantity'
    );
    // 条件更新失败时抛出业务异常，确保订单不会单独提交。
    $decreaseStock->execute([
        'quantity' => $quantity,
        'id' => $itemId,
    ]);
    if ($decreaseStock->rowCount() !== 1) {
        throw new RuntimeException('库存不足或商品不存在');
    }

    // 只有订单和库存都完成，才离开事务边界。
    $pdo->commit();
} catch (Throwable $error) {
    // 回滚后抛出原错误，让接口层返回一致的失败结果。
    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }
    throw $error;
}
?>

这里的 rowCount() 只是业务条件示例，实际含义取决于驱动和 SQL。重点是：业务判断也应发生在 commit() 之前，不能先提交再发现库存条件不满足。

哪些情况会让回滚看起来“不生效”

回滚能否撤销数据，不只取决于 PHP 代码。PDO 事务页面明确提醒，底层驱动可能不支持事务；某些数据库执行 CREATE TABLE、DROP TABLE 等 DDL 时会隐式提交；MySQL 的 MyISAM 表也不能按 InnoDB 的方式提供事务回滚。

用三层检查确认问题在代码还是数据库

遇到“代码执行了 rollBack() 但数据还在”时，可以按下面三层查找，不需要先修改业务代码。

1. 看 PDO 状态：确认 beginTransaction() 的返回值和异常日志，记录失败发生在开启事务前还是某条 SQL 执行后。
2. 看 SQL 范围：检查是否在 commit() 前执行了 DDL，是否有隐藏的提交调用，是否把某次写入放到了事务外。
3. 看数据库能力：确认实际连接的驱动、表引擎和事务配置，不要只根据 beginTransaction() 返回成功就断定所有写入可回滚。

另外，PHP 脚本结束或连接关闭时，尚未完成的事务通常会自动回滚，但这只能作为异常退出时的兜底，不能代替显式的 commit() 和 rollBack()。正常业务路径仍应明确写出成功提交与失败回滚。

常见问题

为什么 catch 里不能直接写 rollBack？

因为异常可能发生在连接创建或开启事务之前，也可能发生在事务已经提交之后。没有活动事务时，rollBack() 自己可能抛异常，所以应先判断 inTransaction()。

PDO 能否回滚 CREATE TABLE？

不能一概而论。不同数据库对 DDL 的事务语义不同，MySQL 和 Oracle 等场景会发生隐式提交，导致同一事务中更早的修改无法按预期撤销。业务事务中应避免混入 DDL。

手动执行 BEGIN 能代替 beginTransaction 吗？

不建议把两者混用。PDO 只有在通过 beginTransaction() 启动时，才知道事务状态并能配合 inTransaction() 与自动回滚语义管理边界。

回滚后还要重新设置自动提交吗？

正常 PDO 事务在提交或回滚后会回到自动提交模式。下一次独立的业务单元开始前，再显式调用 beginTransaction() 即可。

最后可以把这条规则写进代码审查清单：所有相关写操作都在显式事务内；commit() 只出现在成功出口；异常路径先判断 inTransaction() 再回滚；事务内不混入会隐式提交的 DDL；连接与表的事务能力已经确认。满足这些条件时，PDO 异常回滚才是可控的业务边界，而不是 catch 中的一句补救代码。