ThinkPHP中废弃的数据库事务处理写法_使用闭包事务管理技巧

ThinkPHP 5.1+ 中 startTrans/commit/rollback 为什么突然不生效了

因为从 ThinkPHP 5.1 开始，Db::startTrans() 等手动事务控制在「非闭包模式下」已不再自动绑定当前连接实例，尤其在使用连接池、多数据库或模型切换时，事务容易作用于错误的连接，甚至静默失败。

常见错误现象：rollback() 执行后数据仍被写入；commit() 报错 There is no active transaction；日志里看不到 BEGIN/COMMIT 语句。

根本原因是：TP 默认使用「连接惰性初始化」，startTrans() 调用时可能尚未真正获取到 PDO 实例，后续操作却走的是另一个新连接多模型混用（比如 User::create() 和 Db::table(‘log’)->insert()）时，两者底层连接对象很可能不同闭包事务（Db::transaction()）会强制复用同一连接，并确保异常时自动回滚，这才是官方推荐路径

必须改用 Db::transaction() 闭包写法的三个硬性场景

不是“建议”，而是某些情况下不用闭包就根本不可靠：

涉及多个模型操作（如同时更新 User 和 Order 模型），模型各自持有可能不同的数据库连接混合使用 Db:: 查询和模型方法（save()、delete()），它们默认不共享事务上下文启用了读写分离或连接池配置（’deploy’ => 1），手动事务无法跨节点保证原子性

示例对比：

立即学习“PHP免费学习笔记（深入）”；

// ❌ 危险写法（TP 5.1+ 不再可靠）Db::startTrans();try { User::create([‘name’ => ‘A’]); Db::table(‘log’)->insert([‘msg’ => ‘created’]); Db::commit();} catch (\Exception $e) { Db::rollback(); throw $e;}// ✅ 唯一推荐写法Db::transaction(function () { User::create([‘name’ => ‘A’]); Db::table(‘log’)->insert([‘msg’ => ‘created’]);});

Db::transaction() 的参数和超时陷阱

它支持第二个参数指定隔离级别，但很多人忽略其底层依赖 PDO 的 beginTransaction() 行为，而 MySQL 对隔离级别的实际支持有限。

可传值：Db::TRANSACTION_READ_UNCOMMITTED、Db::TRANSACTION_READ_COMMITTED、Db::TRANSACTION_REPEATABLE_READ（MySQL 默认）、Db::TRANSACTION_SERIALIZABLE传错值（如字符串 ‘READ COMMITTED’）不会报错，但会被 PDO 忽略，降级为默认级别事务执行时间超过 MySQL 的 wait_timeout（默认 8 小时）不会自动中断，但连接可能被服务端断开，导致后续 commit 失败并抛出 PDOException: MySQL server has gone away闭包内不要做耗时同步操作（如 HTTP 请求、大文件处理），否则极易触发超时或锁表

模型层事务不能只靠 Db::transaction()

如果业务逻辑全在模型里，直接调 Db::transaction() 可能割裂领域逻辑。此时应把事务控制权上提到 Service 层，而非在模型内部硬编码。

模型本身不负责事务边界 —— 它只管单条记录的持久化语义多个模型协作的事务，必须由调用方（通常是 Service 或 Controller）用 Db::transaction() 包裹，否则模型间无法感知彼此事务状态切忌在模型的 beforeWrite 钩子中调用 Db::startTrans()：钩子执行时机不可控，且可能嵌套触发多次事务启动如果真需要模型级事务封装，应提供一个显式接受闭包的静态方法，例如 User::inTransaction(fn() => […])，内部仍委托给 Db::transaction()

事务不是开关，是上下文。闭包强制你把「什么该一起成功或失败」这个判断显式写出来，而不是靠一堆 if-else 和散落各处的 commit 来拼凑一致性 —— 这才是废弃老写法最根本的原因。