Db::startTrans() 在 ThinkPHP 5.1+ 中总不回滚，因其脱离连接上下文管理，事务控制与 SQL 执行可能不在同一 PDO 连接；正确写法仅 Db::transaction() 闭包模式，它自动绑定并锁定连接，异常时自动回滚。
Db::startTrans() 在 ThinkPHP 5.1+ 中为什么总不回滚
因为 Db::startTrans()、Db::commit()、Db::rollback() 这套手动事务写法，在 TP 5.1+ 中已脱离连接上下文管理，调用时可能根本没绑定到你正在操作的那个数据库连接上。
常见错误现象包括：rollback() 执行了但数据还在；commit() 报错 There is no active transaction；日志里完全看不到 BEGIN 语句。
根本原因是：TP 默认启用连接惰性初始化，startTrans() 调用时 PDO 实例可能还没创建，而后续 db('xxx')->update() 却触发了新连接，导致事务控制和实际 SQL 执行不在同一个连接里。
无序列表说明关键点：
立即学习“PHP免费学习笔记（深入）”；
-
db('table')是助手函数，返回的是全新 Db 实例，与Db::startTrans()不共享连接 - 必须统一使用
Db::name('table')或模型对象（如User::create()），它们复用当前 Db 连接实例 - 多模型混用（比如
User::create()+Db::table('log')->insert()）极易跨连接，事务失效 - 即使单表操作，若中间有其他 Db 调用（如查询配置、日志写入），也可能触发连接切换
正确写法只有 Db::transaction() 闭包一种
ThinkPHP 5.1+ 官方唯一推荐且能保证原子性的写法是 Db::transaction() 闭包模式，它会在闭包执行前自动获取并锁定当前连接，异常时自动 rollback()，成功后自动 commit()。
示例：
Db::transaction(function () {
Db::name('user')->insert(['name' => 'a']);
Db::name('log')->insert(['action' => 'register']);
});
这个闭包内所有 Db::name() 调用都强制走同一个连接，且整个过程不可中断 —— 即使中间抛出未捕获异常，也会触发回滚。
注意点：
- 闭包外不能调用
Db::commit()或Db::rollback()，会报错或静默忽略 - 闭包内不要用
db('user')，只认Db::name('user')或模型方法 - 如果闭包里需要返回值，直接
return $result，它会原样透出，不影响事务
事务失效的两个底层硬性前提
就算代码写对了，事务也有可能「物理上无法回滚」—— 这和 ThinkPHP 无关，而是 MySQL 层面的硬限制。
必须同时满足以下两点，事务才有意义：
- 数据库连接配置中明确指定
'deploy' => 0（禁用读写分离），否则主从切换会导致事务跨节点失效 - 所有涉及的数据表引擎必须是
InnoDB，MyISAM表完全不支持事务，ALTER TABLE table_name ENGINE=InnoDB可转换
检查方式：
SHOW CREATE TABLE user; -- 输出中需含 ENGINE=InnoDB
很多线上问题其实卡在这一步：开发环境是 InnoDB，测试库或生产某张表被误设为 MyISAM，事务看起来“有时生效有时不”，实则稳定失效。
模型层事务要避免混用 Db 和模型静态方法
用 User::create() 或 $user->save() 开启事务时，必须全程用模型，不能穿插 Db::table() 或 Db::name()。
反例：
User::startTrans();
User::create($data);
Db::name('log')->insert($log); // ❌ 换连接，事务失效
User::commit();
正例（全模型）：
User::startTrans(); User::create($data); LogModel::create($log); // ✅ 同一模型类，复用连接 User::commit();
更稳妥的做法仍是放弃手动事务，改用闭包：
Db::transaction(function () use ($data, $log) {
User::create($data);
LogModel::create($log);
});
复杂业务里最容易被忽略的，是「看似无关的辅助操作」—— 比如在事务中查缓存、发 HTTP 请求、调用另一个服务的 SDK，这些虽不碰 DB，但一旦超时或失败，往往让人误以为是事务问题，其实只是逻辑断点没兜住。
