ThinkPHP中DbTransaction_嵌套事务与Savepoint原理【操作】

先说一个很多 ThinkPHP 开发者踩过的坑：你写了两层 Db::transaction()，以为内层异常会让整个事务回滚，结果数据却只回了一半，外层那些已执行的 SQL 居然正常提交了。问题出在哪？出在框架对“嵌套事务”的实现本质上是一种伪装。

ThinkPHP 的 Db::transaction() 并不支持真正的嵌套事务。所谓的“嵌套”，底层玩的是 MySQL 的 SA VEPOINT（保存点） 机制——简单说就是打一个逻辑标记，而不是开启新的独立事务。理解这个前提，才能避开“内层失败、外层仍提交”的数据不一致陷阱。

为什么 Db::transaction 嵌套调用不会回滚外层？

根本原因在底层实现：

• MySQL 本身不支持嵌套事务——执行 START TRANSACTION 会隐式提交当前事务；
• ThinkPHP 的 Db::transaction() 检测到已经存在事务时，不会再次调用 PDO::beginTransaction()，而是自动创建一个 SA VEPOINT；
• 内层闭包抛出异常时，框架只执行 ROLLBACK TO SA VEPOINT，仅撤回该保存点之后的操作，外层事务状态丝毫不受影响；
• 最终外层闭包正常结束，仍然会触发 commit()，导致外层已执行的 SQL 被完整提交。

换句话说，你以为的“嵌套回滚”，其实只是局部擦除。

如何安全使用 Sa vepoint 实现局部回滚？

假如你确实需要在事务中做“可选回退”的操作——比如先记日志，再试更新，失败时只想撤回更新部分——这时候可以绕过 Db::transaction() 的嵌套糖，直接操作 PDO：

• 用 Db::startTrans() 手动开启事务；
• 执行关键前置操作（如插入日志、锁定订单）；
• 调用 Db::getPdo()->exec('SA VEPOINT sp_update') 创建唯一命名的保存点；
• 执行可能失败的业务逻辑（如扣减库存、生成明细）；
• 失败时执行 Db::getPdo()->exec('ROLLBACK TO SA VEPOINT sp_update')；
• 最后统一判断是 Db::commit() 还是 Db::rollback()。

注意保存点名称不能重复，否则 ROLLBACK TO 的行为可能会变得不可预期。

推荐做法：避免嵌套，收口到单层事务

其实绝大多数业务场景根本不需要嵌套。更健壮、更易维护的方式是把所有关联操作——用户扣款、订单生成、库存变更、日志写入——全部写进同一个 Db::transaction() 闭包中。用函数封装拆分逻辑，但不拆分事务边界。比如 createOrder()、deductBalance() 都在闭包内调用就好。

如果确实需要分层控制（例如支付回调中“主流程必须成功，通知可降级”），那就老老实实用 SA VEPOINT + 手动 PDO 操作，别指望嵌套 transaction 能救你。另外务必确认数据库引擎为 InnoDB，且连接未被意外切换——混用模型与 Db 类时容易踩坑。

常见错误与规避提示

下面这几个细节常常被忽略，但直接导致事务失效：

• Db::startTrans() 后没写 try-catch，或者写了 catch 却忘了调 Db::rollback()；
• 在事务中调用其他含 Db::transaction() 的方法，形成隐式嵌套；
• SA VEPOINT 名称重复，导致 ROLLBACK TO 行为不可预期；
• 事务中执行了非 PDO 操作（如 Redis 写入、文件写入、HTTP 请求），它们无法被回滚，需要额外设计补偿逻辑。

总而言之，把 ThinkPHP 的嵌套事务当成“局部回滚点”来理解，而不是真正的子事务，很多问题就能想通了。