ThinkPHP 8.0 为何事务嵌套失效？Savepoint 机制与底层原理【DBA】-ThinkPHP-PHP中文网

thinkphp 8.0 的 db::transaction() 嵌套调用默认报 runtimeexception: transaction already started，因底层 pdo 不支持嵌套事务且 tp8 主动拒绝模拟；即使传 true 启用 savepoint，也需满足 innodb 引擎、非 read uncommitted 隔离级、连接未被模型切换三条件，否则 savepoint 创建失败；内层异常仅回滚至保存点，外层仍 commit，导致数据部分提交。

thinkphp 8.0 为何事务嵌套失效？savepoint 机制与底层原理【dba】

Db::transaction() 嵌套调用直接报错或静默忽略

ThinkPHP 8.0 默认不启用 SAVEPOINT 支持，两次 Db::transaction() 嵌套会触发 RuntimeException: Transaction already started，而不是回滚外层。这不是语法错误，是框架主动拒绝——底层 PDO 只维护单个事务状态位，第二次 beginTransaction() 被 MySQL 忽略，TP8 选择抛异常而非模拟。

若强行加 true 参数（Db::transaction(fn() => ..., true)），仍需满足三个硬性条件：数据库引擎必须为 InnoDB、隔离级别不能是 READ UNCOMMITTED、连接未被模型自动切换。任意一项不满足，SAVEPOINT 创建失败，后续 ROLLBACK TO SAVEPOINT 就会报 SQLSTATE[HY000]: General error: 1305 SAVEPOINT TP_SAVEPOINT_1 does not exist。

SHOW CREATE TABLE your_table 必须含 ENGINE=InnoDB
SELECT @@tx_isolation 返回值应为 REPEATABLE-READ 或 READ-COMMITTED
避免在 CLI 命令中测试——部分命令未初始化事务上下文，Db::getPdo() 可能返回新连接

内层异常不触发外层回滚，数据部分提交

即使开启 true 参数且环境达标，“嵌套”也仅是 SAVEPOINT 模拟：外层 START TRANSACTION 后，内层实际执行的是 SAVEPOINT sp_xxx；内层异常时只 ROLLBACK TO SAVEPOINT，外层仍会正常 commit()。结果是日志写入成功、库存扣减失败，但订单表已落库。

根本原因在于 MySQL 本身不支持嵌套事务——START TRANSACTION 在已有事务时会隐式提交当前事务，PDO 层无法绕过这一限制。ThinkPHP 的“嵌套”只是业务逻辑分层，不是数据库级原子隔离。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

不要在闭包里 try/catch 吞掉异常，否则 Db::transaction() 无法感知失败
throw new \Error()（如 TypeError）不会被 Db::transaction() 捕获，它只监听 \Exception 子类
混用 UserModel::create() 和 Db::table('order') 极易导致跨连接，事务只作用于当前 Db 实例

手动 SAVEPOINT 操作比嵌套 transaction 更可控

真需要局部回滚（比如先记日志再试更新，失败只撤回更新），绕过 Db::transaction() 嵌套，直接操作 PDO：

Db::startTrans();
Db::table('log')->insert(['action' => 'pay_start']);
Db::getPdo()->exec('SAVEPOINT sp_payment');
try {
    Db::table('stock')->where('id', 1)->dec('num', 1);
} catch (\Exception $e) {
    Db::getPdo()->exec('ROLLBACK TO SAVEPOINT sp_payment');
    throw $e;
}
Db::commit();

注意点：

SAVEPOINT 名必须唯一，避免并发冲突，建议带业务前缀如 sp_payment_123
ROLLBACK TO SAVEPOINT 不影响连接状态，但后续不能再用同名保存点
执行 ROLLBACK TO SAVEPOINT 后，必须显式 throw 异常，否则外层逻辑可能继续执行

跨模型/跨库事务失效的底层根源

Db::startTrans() 或 Db::transaction() 都绑定在单个 PDO 实例上。调用 UserModel::create() 时，若模型未显式复用默认连接，会新建一个 PDO 连接，事务对其无效。跨库更是如此：Db::connect('order_db') 和 Db::connect('user_db') 是两个完全隔离的连接，不存在“全局事务”概念。

MySQL 原生 XA 事务在生产环境极少使用——死锁率高、超时难诊断、运维成本远超应用层补偿。真正可行的方案是：主库写成功 + 写幂等日志 + 异步重试辅库，失败走人工核对。