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()，每一条都独立走验证和事件，**默认完全不开启事务**。某条失败，前面成功的不会回滚，还可能因字段不一致直接中断。
- 默认行为：无事务、无回滚、无批量原子性
- 想安全批量写入，必须手动包事务：
Db::transaction(function () use ($data) { User::saveAll($data); }); - 但要注意：
saveAll()里任一条验证失败（比如邮箱格式错），整个闭包会抛异常触发回滚；而字段缺失（如第二条多出phone字段）则直接报MySQL错误，事务也会滚 - 性能提示：开启事务后
saveAll()仍是逐条执行，不是一条INSERT ... VALUES(...),(...),(...)，别指望它变原生批量插入
真正容易被忽略的是：模型层和Db事务层是两套平行系统，你以为包了Db::transaction()就万事大吉，但只要中间穿插了没走同一PDO连接的操作（比如用new PDO()直连、或调用了非框架封装的第三方SDK），事务就失效了。确认是否生效，最简单的方法是在事务块里故意抛异常，看前面的save()是否真被撤回。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
