ThinkPHP事务操作怎么写_startTrans、commit、rollback【教程】

ThinkPHP里的Db::startTrans()，看起来像是事务的开关，但真用起来，坑比想象的多。不少开发者以为调了它就能自动回滚，结果数据写错了都不知道。今天直接把这几个最要命的问题拆开说清楚。

别指望startTrans()一开就能自动收拾烂摊子。它就是个手动标记，告诉数据库“从这开始，后面的操作先别写死”。至于到底提交还是回滚，全靠你后续手工配对。

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()、或配置了读写分离且写操作被路由到从库，事务就立刻失效——这种问题往往查日志都看不出，得盯住连接实例本身。