Db::transaction()闭包用法不必须传参，但无参仅返回事务对象需手动管理；传闭包才自动开启/提交/回滚。嵌套事务不生效，仅外层起作用；混合操作需注意连接复用与隔离级别；异常被catch住会导致回滚失效。
ThinkPHP 的 Db::transaction() 闭包用法必须传参吗？
不必须，但强烈建议显式传入闭包——否则事务不会自动开启/提交/回滚。ThinkPHP 的 Db::transaction() 是一个“双模式”函数：无参数调用时仅返回事务对象（需手动 start()/commit()/rollback()），传入闭包才启用自动事务管理。
常见错误是写成 Db::transaction(); 然后在外部执行 SQL，结果事务根本没生效，数据直接写入了库。
- 正确写法：
Db::transaction(function () { Db::table('user')->insert([...]); Db::table('log')->insert([...]); }); - 闭包内任意位置抛出异常（
throw new Exception()或未捕获的DbException）会自动触发回滚 - 闭包正常结束，框架自动
commit()；无需手动干预 - 若需在闭包中提前退出但不报错，可用
return false;—— 这会中断执行并回滚（ThinkPHP 6.0.10+ 支持）
嵌套事务在 ThinkPHP 中是否生效？
不生效，ThinkPHP 默认不支持真正的嵌套事务（即 savepoint）。多次调用 Db::transaction() 闭包，实际只有一层外层事务起作用；内层闭包的“回滚”只是提前 return，不会建立保存点。
典型误用场景：A 方法开启事务并调用 B 方法（B 也写了 Db::transaction(...)），结果 B 抛异常只让 B 内部逻辑退出，A 仍继续执行并最终 commit。
立即学习“PHP免费学习笔记（深入）”；
- 解决办法：统一由最外层业务方法控制事务，内部方法不要自行调用
Db::transaction() - 如真需局部回滚，手动用
Db::startTrans()+Db::rollback()+Db::commit()，并自己维护 savepoint 标识（需数据库支持，如 MySQL 5.7+） - 注意
Db::transaction()闭包内不能再调用Db::startTrans()，否则会抛PDOException: There is no active transaction
事务中查询、更新、删除混合操作要注意什么？
关键在于连接复用和隔离级别。ThinkPHP 默认使用长连接，同一事务中所有 Db::table() 操作共享底层 PDO 实例，这点没问题；但容易被忽略的是“读已提交”（READ COMMITTED）下可能读不到本事务刚写的记录（尤其在多次 select + update 交替时）。
- 确保所有操作都走同一个
Db实例：避免混用Db::name()和Db::connect()->table()，后者可能新建连接 - 如果需要“读取自己刚插入的数据”，优先用
lastInsertId()或缓存中间结果，而不是再查一次数据库 - 批量操作慎用
insertAll()：它内部可能分批次执行，若中途失败，已插入的部分不会自动回滚（除非整个闭包因异常退出） - 事务内调用模型事件（如
afterWrite）要小心——事件回调里再操作数据库，同样受当前事务上下文约束
如何调试事务没回滚的问题？
最常见原因是异常被静默捕获了。ThinkPHP 的 Db::transaction() 只对未被捕获的 Throwable 做回滚，一旦你在闭包里写了 try...catch 却没重新 throw，事务就稳稳 commit 了。
- 检查闭包内是否有
try/catch，尤其是日志、通知类代码常自带兜底 catch - 开启数据库日志：
'debug' => true在数据库配置中，观察 SQL 是否真有ROLLBACK输出 - 在闭包末尾加
throw new \Exception('test rollback');测试回滚是否触发——这是最直接的验证方式 - 注意时序：事务闭包执行完才 commit，所以
echo或Log::info()打印的内容，不能代表数据已落库
