PHP PDO 事务嵌套调用的业务边界

PHP PDO 的事务不能像普通函数那样直接层层嵌套。一次 PDO 连接只有一个当前事务，第二次调用 beginTransaction() 会抛出异常；内层直接 commit() 还会提前结束外层事务。稳妥的做法是让最外层业务拥有提交权，内层服务只执行 SQL 并把异常继续抛出；如果某个子操作允许失败，再使用保存点表达“局部回滚”。

官方文档地址：https://www.php.net/manual/en/pdo.transactions.php

判断标准很简单：谁创建了事务，谁负责最终提交或回滚；被调用的方法不要擅自开启、提交或清理同一连接上的外层事务。

为什么直接嵌套 beginTransaction 会失效

PDO::beginTransaction() 会关闭自动提交模式，直到 commit() 或 rollBack() 才恢复。PDO 原生 API 不会为每次方法调用自动创建独立事务，所以“订单服务开启事务，再调用库存服务开启事务”的写法实际上是在同一连接上第二次开启事务。

beginTransaction();

try {
    $orderService->create($pdo, $orderData);
    $inventoryService->reserve($pdo, $items);
    $pdo->commit();
} catch (Throwable $e) {
    // 只有当前连接仍在事务中时才尝试回滚。
    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }
    throw $e;
}

function reserve(PDO $pdo, array $items): void
{
    // 错误示例：这里不应再次 beginTransaction 或 commit。
    $pdo->beginTransaction();
    // ...执行库存更新...
    $pdo->commit();
}
?>

内层的 commit() 也不是“提交自己的那几条 SQL”，而是提交当前连接自事务开始以来的全部改动。即使某些数据库支持保存点，也不能把多个 beginTransaction() 当作自动嵌套事务。

让最外层服务统一 commit 和 rollBack

我在业务代码里更倾向于把事务模板放在用例服务，而不是每个 Repository 或子服务里。这样一条业务链只有一个事务入口，内层方法的职责也更清楚：执行自己的写操作，遇到无法继续的情况抛出异常。

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $pdo->beginTransaction();

    try {
        $orderId = insertOrder($pdo, $order);
        reserveItems($pdo, $orderId, $items);
        writeOrderLog($pdo, $orderId);

        // 只有最外层用例完成全部写操作后才提交。
        $pdo->commit();
        return $orderId;
    } catch (Throwable $e) {
        // 回滚前先确认连接没有被提前提交或回滚。
        if ($pdo->inTransaction()) {
            $pdo->rollBack();
        }
        throw $e;
    }
}

function reserveItems(PDO $pdo, int $orderId, array $items): void
{
    $statement = $pdo->prepare(
        'UPDATE inventory SET available = available - :quantity
         WHERE sku = :sku AND available >= :quantity'
    );

    foreach ($items as $item) {
        // 影响行数为 0 表示库存不足，让外层统一回滚订单。
        $statement->execute([
            'quantity' => $item['quantity'],
            'sku' => $item['sku'],
        ]);
        if ($statement->rowCount() !== 1) {
            throw new RuntimeException('库存不足：' . $item['sku']);
        }
    }
}
?>

这种设计的关键不是把 PDO 对象到处传递，而是明确事务所有权。Repository 可以接收一个已经存在的连接，但不应在内部改变事务状态。异常一旦离开内层方法，外层就能决定整条用例失败，避免出现“订单已提交、库存却回滚”的半成功结果。

需要局部撤销时使用 SAVEPOINT

有些业务并不是“子操作失败就整单失败”。例如写入一条可选的审计扩展记录失败时，主订单仍可以继续，但这需要数据库的保存点能力，而不是再次调用 beginTransaction()。保存点依附在外层事务中，ROLLBACK TO SAVEPOINT 只撤销保存点之后的改动。

exec('SAVEPOINT ' . $savepoint);

    try {
        $statement = $pdo->prepare(
            'INSERT INTO order_audit (order_id, payload) VALUES (:order_id, :payload)'
        );
        $statement->execute([
            'order_id' => $orderId,
            'payload' => json_encode($payload, JSON_THROW_ON_ERROR),
        ]);

        // 子操作成功后释放保存点，但不提交外层事务。
        $pdo->exec('RELEASE SAVEPOINT ' . $savepoint);
    } catch (Throwable $e) {
        // 只回到保存点，调用方仍可继续使用当前外层事务。
        $pdo->exec('ROLLBACK TO SAVEPOINT ' . $savepoint);
        $pdo->exec('RELEASE SAVEPOINT ' . $savepoint);
    }
}
?>

保存点适合“可选子操作”或需要在一条事务里尝试多个候选动作的场景。它仍然受外层 commit() 约束：外层最终回滚时，保存点之后保留下来的改动同样会消失。不同数据库对保存点、存储引擎和 DDL 的支持存在差异，部署前应以目标驱动和数据库文档为准。

异常清理和发布前的边界检查

统一模板时，重点检查四个边界：

• 事务开启后，所有可能抛错的写操作都在同一个 try 范围内。
• catch 中先用 inTransaction() 判断，再调用 rollBack()，避免二次清理覆盖原始异常。
• 内层方法不调用 commit()、rollBack() 或第二次 beginTransaction()，除非它明确拥有独立连接。
• 不要把依赖隐式提交的 DDL 混进数据事务；某些数据库执行 CREATE TABLE、DROP TABLE 等语句时会自动提交。

如果确实需要内层独立提交，应该显式创建另一条数据库连接，并接受它不再和外层事务保持原子性。大多数订单、支付、库存和账务用例不应采用这种方式，而应把事务边界提升到共同的用例层。

常见问题

PDO 能不能自动识别嵌套事务？

不能。原生 PDO 只跟踪当前连接的事务状态，第二次 beginTransaction() 会失败。需要局部回滚时应使用数据库保存点或重构调用边界。

内层方法为什么不能直接 commit？

因为它无法知道外层是否还有后续写操作。提前提交会让后续失败只能回滚剩余部分，破坏整条业务的一致性。

保存点是不是完整的嵌套事务？

不是。保存点提供局部撤销位置，但最终提交和最终回滚仍由外层事务决定；它也不能抵消数据库对某些 DDL 的隐式提交行为。

小结：把事务所有权放在最外层；内层只做业务写入并抛出异常；需要局部撤销时使用固定保存点。这样提交、回滚和异常处理的职责不会随着服务调用层级扩散。