为什么ThinkPHP模型save方法默认不参与事务【避坑】

ThinkPHP模型的save()方法默认不参与事务，是设计选择而非bug；它只负责单条数据生命周期，需显式用Db::transaction()包裹才能纳入事务。

ThinkPHP模型的save()方法本身不参与事务，不是bug，是设计选择——它只管“单条数据生命周期”，事务必须由你显式包裹。

save() 为什么默认游离于事务之外

模型save()底层调用的是PDO的execute()，它不感知当前是否有活跃事务。即使你在外部手动Db::startTrans()了，$user->save()也不会自动加入——它只认自己那一行SQL是否执行成功，不关心上下文。

• 框架层未做事务绑定：模型操作和Db类事务是两套独立机制，没有隐式桥接
• 验证/事件钩子优先级更高：save()先跑验证、自动时间戳、beforeSave事件等，事务提交在最后一步，中间任意环节失败就中断，不会回滚前面已执行的SQL
• 兼容性考虑：部分场景（如日志写入）确实需要“不管事务成败都落库”，放开控制权更灵活

save() 被事务包裹的正确姿势

想让它进事务，必须用Db::transaction()或手动Db::startTrans() + Db::commit()/Db::rollback()，且所有操作必须统一用Db类或同一模型实例——混用会断链。

• ✅ 推荐：用Db::transaction()闭包，把save()和其他Db操作全塞进去

  Db::transaction(function () {<br>  $user = new User();<br>  $user->name = 'test';<br>  $user->save(); // 这条进了事务<br>  Db::name('log')->insert(['msg' => 'user created']);<br>});

• ⚠️ 注意：Db::transaction()内部若调用其他模型方法（如$user->profile->save()），需确保子模型也走同一事务上下文，否则可能漏掉
• ❌ 错误示范：Db::startTrans(); $user->save(); Db::commit(); —— 模型save()不认Db::startTrans()，这条save仍游离在外

saveAll() 和事务的典型陷阱

saveAll()本质是循环调用save()，每一条都独立走验证和事件，**默认完全不开启事务**。某条失败，前面成功的不会回滚，还可能因字段不一致直接中断。

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

• 默认行为：无事务、无回滚、无批量原子性
• 想安全批量写入，必须手动包事务：Db::transaction(function () use ($data) { User::saveAll($data); });
• 但要注意：saveAll()里任一条验证失败（比如邮箱格式错），整个闭包会抛异常触发回滚；而字段缺失（如第二条多出phone字段）则直接报MySQL错误，事务也会滚
• 性能提示：开启事务后saveAll()仍是逐条执行，不是一条INSERT … VALUES(…),(…),(…)，别指望它变原生批量插入

真正容易被忽略的是：模型层和Db事务层是两套平行系统，你以为包了Db::transaction()就万事大吉，但只要中间穿插了没走同一PDO连接的操作（比如用new PDO()直连、或调用了非框架封装的第三方SDK），事务就失效了。确认是否生效，最简单的方法是在事务块里故意抛异常，看前面的save()是否真被撤回。