PHP PDO 事务完整工作流：开启事务、提交、回滚和异常模式

PHP 项目里只要一次操作会改多张表，就很容易遇到“前面写入成功，后面失败，数据只保存了一半”的问题。比如创建订单时，先写订单主表，再扣库存，再写订单明细。如果中间任何一步失败，最好让前面的修改一起撤回，这就是事务要解决的核心问题。

这篇文章不只讲一个函数怎么调用，而是把 PDO 事务整理成一套可复用工作流：什么时候开启事务、每个阶段检查什么、失败后怎么回滚、最后如何确认数据一致。按这个流程写，代码会更稳，也更容易排查线上数据不一致问题。

摘要

PDO 事务的推荐流程是：连接后先设置错误模式，进入业务写入前开启事务，多条写入都成功后提交；任意一步失败时进入异常处理，确认仍在事务中就回滚。最后不要只相信接口返回成功，还要检查主表、明细表和库存变化是否一致。

适合人群

• 正在用 PHP 和 PDO 操作 MySQL 的后端开发者。
• 需要处理订单、库存、余额、积分、日志等多表写入场景的项目维护者。
• 遇到过接口报错后数据库只保存一部分数据，想系统整理事务写法的读者。

目标和边界：事务要保证什么

先把边界定清楚：事务不是让 SQL 永远不报错，也不是自动帮我们修复业务数据。它解决的是一组数据库修改的“一起成功，或者一起撤回”。因此，适合放进同一个事务里的操作，通常有明确的业务一致性要求。

本文示例假设数据库表使用支持事务的存储引擎，比如 MySQL InnoDB。还要注意，事务应该尽量短，业务校验要放在合适位置，避免把耗时网络请求、文件处理、复杂计算长时间放在事务中。

全流程总览：一次 PDO 事务从开启到结束

完整流程可以压缩成五个动作：接收 PHP 请求，开启事务，写主表，写明细，最后提交；如果中间任何一步失败，就走回滚路径。重点不是把代码包进 try 里就结束，而是每个阶段都要有明确检查点。

到这一步先记住一个判断标准：只要后续失败会让前面写入失去意义，就应该考虑放在同一个事务中。比如订单主表已经插入，但明细插入失败，这个订单对用户来说就是不完整的。

阶段一：连接后先设置异常模式

第一阶段的目标，是让数据库错误不要静默过去。PDO 默认错误处理方式如果配置不合适，某条 SQL 失败后可能只是返回错误状态，后面的提交逻辑仍然继续走。这样最容易出现“看起来成功，实际数据不完整”。

推荐在创建连接后立刻设置错误模式：

$dsn = 'mysql:host=127.0.0.1;dbname=demo;charset=utf8mb4';
$pdo = new PDO($dsn, 'demo_user', 'demo_pass');

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

这一阶段的检查点很简单：写一条确定会失败的测试 SQL，确认代码能进入错误处理分支。不要在生产环境随意测试，可以在本地测试库或单元测试里验证。

阶段二：把多条写入包进同一个事务

第二阶段的目标，是让同一组业务写入共享一个事务边界。下面用“创建订单、扣库存、写订单明细”做示例。为了突出事务流程，这里用 query() 演示，实际项目中参数来源于用户输入时，应改用参数绑定方案。

try {
    $pdo->beginTransaction();

    $pdo->query(\"INSERT INTO orders (user_id, total_amount, status)
        VALUES (1001, 19900, 'pending')\");

    $orderId = $pdo->lastInsertId();

    $pdo->query(\"UPDATE products
        SET stock = stock - 1
        WHERE id = 7 AND stock > 0\");

    $changedRows = $pdo->query(\"SELECT ROW_COUNT()\")->fetchColumn();
    if ((int) $changedRows !== 1) {
        throw new RuntimeException('库存不足，订单不能继续创建');
    }

    $pdo->query(\"INSERT INTO order_items (order_id, product_id, quantity, price)
        VALUES ({$orderId}, 7, 1, 19900)\");

    $pdo->commit();
} catch (Throwable $error) {
    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }

    throw $error;
}

这一阶段的关键动作有三个：在第一条写入前开启事务，在所有写入成功后提交，在业务条件不满足时主动抛出错误信号。库存扣减就是典型检查点，不能只看 SQL 没报错，还要看影响行数是否符合预期。

阶段三：失败时回滚并保留错误信号

第三阶段的目标，是失败后既要撤回数据库修改，也要让上层知道这次操作没有成功。不要在错误处理里只写回滚，然后直接返回“成功”。那样前端和调用方会误以为订单创建完成。

建议错误处理逻辑保持三步：

1. 先判断 inTransaction()，仍在事务中再回滚。
2. 记录必要的错误上下文，比如用户 ID、商品 ID、订单临时信息。
3. 把错误继续交给上层处理，让接口返回失败状态。

为什么要判断 inTransaction()？因为某些失败可能发生在事务开启前，或者提交之后。直接调用回滚可能带来新的错误。先判断当前状态，可以让错误处理更稳。

我的推荐流程

把上面的内容落成项目规范，可以按下面顺序执行：

如果这套流程要封装成公共方法，建议封装的是“事务边界”和“错误处理”，不要把具体业务 SQL 硬塞进通用函数。业务校验往往和订单、库存、余额规则强相关，过度封装反而会让排查更难。

容易踩坑的地方

1. 只开启事务，没有打开异常模式

这会让部分失败不够明显。事务外壳看起来存在，但错误没有及时打断流程，最后仍可能提交不完整数据。连接创建后先设置错误模式，是事务代码的基础动作。

2. 事务里夹杂耗时外部操作

事务应该尽量短。如果在事务中调用远程接口、上传文件、生成复杂报表，数据库连接和锁可能被占用太久。更稳的方式是先完成必要数据库修改，提交后再通过任务队列处理后续动作。

3. 回滚后吞掉错误

回滚只是把数据库改动撤回，不代表业务已经成功。错误处理分支要让上层知道失败原因，否则调用方可能继续走“支付成功”“发货成功”之类后续流程。

4. 不检查影响行数

很多 SQL 没有报错，不代表业务成功。比如库存为 0 时，带 stock > 0 条件的扣减语句可能影响 0 行，这时就应该主动进入失败分支，而不是继续写订单明细。

落地速查表

总结一下：PDO 事务的重点不是记住某几个方法名，而是把“开启、写入、校验、提交、回滚、确认”串成固定流程。只要每个阶段都有检查点，多表写入就不容易留下半截数据，后续排查也会更清楚。