ThinkPHP 8.0 的 Db::transaction() 嵌套调用默认报 RuntimeException: Transaction already started，因底层 PDO 不支持嵌套事务且 TP8 主动拒绝模拟；即使传 true 启用 SAVEPOINT，也需满足 InnoDB 引擎、非 READ UNCOMMITTED 隔离级、连接未被模型切换三条件，否则 SAVEPOINT 创建失败；内层异常仅回滚至保存点，外层仍 commit，导致数据部分提交。
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 的“嵌套”只是业务逻辑分层，不是数据库级原子隔离。
立即学习“PHP免费学习笔记（深入）”；
- 不要在闭包里
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 事务在生产环境极少使用——死锁率高、超时难诊断、运维成本远超应用层补偿。真正可行的方案是：主库写成功 + 写幂等日志 + 异步重试辅库，失败走人工核对。
- 所有事务内操作统一用
Db::name('table')，避免模型自动建连 - 若必须用模型，强制指定连接：
protected $connection = 'default';，并在事务前清空模型查询缓存 - 调试时查日志，出现多条
START TRANSACTION即说明事务已分散到不同连接
