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

thinkphp 5.1+ 中 starttrans/commit/rollback 不生效，是因为手动事务在非闭包模式下不绑定当前连接实例，易作用于错误连接；必须改用 db::transaction() 闭包写法以确保连接一致性和自动回滚。

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），手动事务无法跨节点保证原子性

示例对比：

// ❌ 危险写法（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 来拼凑一致性 —— 这才是废弃老写法最根本的原因。