ThinkPHP 的 Db::transaction() 不支持真正嵌套事务，其“嵌套”实为基于 MySQL SAVEPOINT 的模拟；内层异常仅回滚至保存点，外层仍会提交，导致数据不一致。
ThinkPHP 的 Db::transaction() 不支持真正意义上的嵌套事务，所谓“嵌套”实际是通过 MySQL 的 SAVEPOINT（保存点） 模拟实现的逻辑分层，并非开启多个独立事务。理解这一点，才能避免“内层失败、外层仍提交”的数据不一致陷阱。
为什么 Db::transaction 嵌套调用不会回滚外层？
根本原因在底层机制：
- MySQL 本身不支持嵌套事务，执行
START TRANSACTION会隐式提交当前事务； - ThinkPHP 的
Db::transaction()在检测到已存在事务时，不会再次调用PDO::beginTransaction()，而是自动创建一个 SAVEPOINT； - 内层闭包抛出异常时，框架只执行
ROLLBACK TO SAVEPOINT，仅撤回该保存点之后的操作，外层事务状态不受影响； - 最终外层闭包正常结束，仍会触发
commit()，导致外层已执行的 SQL 被提交。
如何安全使用 Savepoint 实现局部回滚？
若需在事务中做“可选回退”的操作（例如：先记日志，再试更新，失败则只撤回更新），应绕过 Db::transaction() 嵌套，直接操作 PDO：
- 用
Db::startTrans()手动开启事务； - 执行关键前置操作（如插入日志、锁定订单）；
- 调用
Db::getPdo()->exec('SAVEPOINT sp_update')创建唯一命名的保存点； - 执行可能失败的业务逻辑（如扣减库存、生成明细）；
- 失败时执行
Db::getPdo()->exec('ROLLBACK TO SAVEPOINT sp_update')； - 最后统一判断是否
Db::commit()或Db::rollback()。
推荐做法：避免嵌套，收口到单层事务
绝大多数业务场景无需嵌套。更健壮、更易维护的方式是：
立即学习“PHP免费学习笔记（深入）”；
- 把所有关联操作（用户扣款、订单生成、库存变更、日志写入）全部写进同一个
Db::transaction()闭包中； - 用函数封装拆分逻辑，但不拆分事务边界，例如：
createOrder()、deductBalance()都在闭包内调用； - 如确需分层控制（如支付回调中“主流程必须成功，通知可降级”），用 SAVEPOINT + 手动 PDO 操作，而非依赖嵌套 transaction；
- 务必确认数据库引擎为 InnoDB，且连接未被意外切换（混用模型与 Db 类时易出问题）。
常见错误与规避提示
这些细节容易被忽略，却直接导致事务失效：
-
Db::startTrans() 后没写 try-catch，或写了 catch 却忘了调
Db::rollback()； - 在事务中调用其他含
Db::transaction()的方法，形成隐式嵌套； - SAVEPOINT 名称重复，导致
ROLLBACK TO行为不可预期； - 事务中执行了非 PDO 操作（如 Redis 写入、文件写入、HTTP 请求），它们无法被回滚，需额外设计补偿逻辑。
