db::starttrans()仅开启事务不自动回滚，必须手动配对db::commit()或db::rollback()；混用db::transaction()、跨库操作、嵌套调用或调试中断均导致事务失效。
Db::startTrans() 不是“开了就能自动回滚”的开关，它只是手动标记事务起点；漏写 commit() 或 rollback()，或者在多层分支里路径遗漏，数据就永久写进去了。
Db::startTrans() 必须配对 commit()/rollback() 才生效
ThinkPHP 的 Db::startTrans() 不会自动捕获异常，也不隐式管理状态。它只做一件事：告诉当前 PDO 连接“从现在起，后续 SQL 要打包成事务”。剩下的全靠你手工收尾。
- 每个
Db::startTrans()后，必须有且仅有一次Db::commit()或Db::rollback() - 不能依赖“脚本结束自动清理”——PHP 进程退出时 PDO 可能直接断连，事务卡在 pending 状态，下个请求可能报
There is no active transaction - 嵌套调用
Db::startTrans()无效：PDO 层不支持真正嵌套，第二次调用被忽略，rollback()只退到最外层 - 推荐加 guard 变量防漏：
$transStarted = false; try { Db::startTrans(); $transStarted = true; ... } finally { if ($transStarted && !isset($committed)) { Db::rollback(); } }
Db::startTrans() 和 Db::transaction() 混用会出事
两者底层机制冲突：Db::transaction() 是异常驱动的闭环（抛异常 → 回滚 → 退出），而 Db::startTrans() 是手动状态机（开 → 判 → 提交/回滚）。混用会导致事务状态错乱，比如：
- 在
Db::transaction()闭包里又调Db::startTrans()：框架无法识别嵌套意图，rollback()可能只退半截 - 先
Db::startTrans()，再进Db::transaction()闭包：闭包内异常触发回滚，但外层手动逻辑还在等commit()，结果重复 rollback 或漏 rollback - 结论：选一个模式贯穿到底，别交叉
跨库操作时 Db::startTrans() 看似执行了，其实没用
事务绑定的是单个 PDO 连接实例。Db::connect('order_db') 和 Db::connect('user_db') 创建的是两个完全独立的连接，各自开启的事务互不感知。
- 你在
user_db上startTrans()，然后切到order_db插一条记录——这条记录根本不在事务范围内 - 常见错误现象：用户表更新成功、订单表插入失败，但程序 catch 到异常后只 rollback 了 user_db 连接，order_db 那条脏数据已提交
- ThinkPHP 不支持跨库事务，所谓“多库事务”只能靠应用层补偿（如发消息、记日志、定时对账），不能靠
startTrans()解决
调试时 dd()/dump() 会让事务卡死
dd() 和 dump() 会强制终止 PHP 执行流，PDO 连接上的事务状态不会被清理，连接仍处于 “transaction active” 状态。
- 后续请求复用该连接时，
Db::startTrans()会失败，报There is no active transaction或直接抛 PDOException - 开发中务必禁用这些函数，改用
Log::info()或var_dump()+exit（注意 exit 前手动 rollback） - 线上环境更不能出现，否则可能引发连接池耗尽、事务堆积
最易被忽略的一点：事务是否生效，和你用的是模型方法还是 Db::table() 无关，只取决于是否复用同一连接；但只要中间有一次 Db::connect()、或配置了读写分离且写操作被路由到从库，事务就立刻失效——这种问题往往查日志都看不出，得盯住连接实例本身。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
