ThinkPHP 8 的 Db::transaction() 嵌套默认不生效，因 PDO 和 MySQL 不原生支持嵌套事务；TP8 虽引入 savepoint 机制，但需外层显式传 true 启用，且依赖 InnoDB 引擎与非 READ UNCOMMITTED 隔离级别。
ThinkPHP 8 的 Db::transaction() 嵌套调用默认不生效，不是 bug，而是设计限制——外层事务不会感知内层失败，数据可能部分提交。根本原因是 PDO 和 MySQL 不原生支持嵌套事务，TP8 虽引入 savepoint 机制，但需手动开启且有严格前提。
为什么直接嵌套会抛 RuntimeException: Transaction already started
TP8 底层已切换为基于 PDO savepoint 的嵌套模拟，但默认关闭。外层调用 Db::transaction() 后，连接状态已是 “in transaction”，此时再调用一次会触发 RuntimeException: Transaction already started。
- 必须显式传参
true：外层要用Db::transaction(fn() => ..., true)启用 savepoint 模式 - 内层不能也用
Db::transaction()，否则仍会冲突；应改用Db::savepoint('sp_name')+Db::rollbackTo('sp_name') - MySQL 必须是
InnoDB引擎，且隔离级别不能是READ UNCOMMITTED（该级别下 savepoint 无效）
Db::transactionLevel() 是唯一可靠的嵌套层级判断依据
别依赖 Db::inTransaction() 或手写计数器——它只反映“是否在事务中”，不区分层级。真正需要局部回滚时（比如记日志成功、更新失败只撤回更新），必须靠 Db::transactionLevel() 动态判断当前深度：
- 外层开始前
Db::transactionLevel()返回 0，进入后变为 1 - 内层执行
Db::savepoint('update_step')后，层级不变，但可标记回滚点 - 若更新失败，调用
Db::rollbackTo('update_step')，不影响外层日志写入 - 切忌在闭包里调用
Db::commit()或Db::rollback()，会破坏框架状态
混用模型与 Db 实例导致跨连接，事务彻底失效
常见错误：外层用 UserModel::create()，内层用 Db::table('order')->insert()。这两者极可能走不同连接实例（尤其配置了读写分离或多数据库），事务只作用于当前 Db 实例，跨连接等于没事务。
立即学习“PHP免费学习笔记（深入）”；
- 统一使用
Db::name('user')和Db::name('order')，确保共用同一连接 - 避免在事务闭包中调用
Db::connect('other_db')或新建模型实例（如new OrderModel()） - 验证方式：在闭包末尾加
throw new \Exception('test')，看所有表数据是否全部消失；若只有部分消失，说明连接已分裂
异常被吞掉，savepoint 形同虚设
Db::transaction() 只捕获未被捕获的 \Exception 子类，\Error（如 TypeError、FatalError）和被 try/catch 拦截的异常，都不会触发自动回滚或 savepoint 回退。
- 闭包内禁止任何
try/catch，哪怕只是Log::error($e)也不行 - 若必须捕获，catch 后必须
throw $e或throw new \Exception(..., 0, $e)保留原始上下文 -
Db::transaction()不处理\Error，所以 PHP 8+ 的类型错误、调用不存在方法等，会跳过事务控制直接崩溃，且数据已提交
savepoint 不是银弹。它依赖 MySQL InnoDB 的底层支持，且无法解决连接分裂、异常吞噬、引擎不匹配这三类硬伤。真要分层控制，不如把逻辑收拢到单个事务闭包，或直接操作 PDO 的 savepoint 和 rollbackTo，绕过框架封装更可控。
