thinkphp事件不触发事务回滚，必须在事件回调中显式控制事务；db::transaction()失效常见原因包括闭包内捕获异常未抛出、错误处理器干扰、exit/die中断、手动commit后异常等。
ThinkPHP 的事件本身不触发事务，也不会自动回滚数据——回滚只发生在数据库事务中，而事件只是 PHP 层的钩子调用。想靠事件“自动”回滚事务，行不通；必须把事务控制逻辑显式写进事件回调里，且严格遵循事务生命周期。
Db::transaction() 闭包里抛异常，为什么有时没回滚？
看似用了 Db::transaction() 就能自动兜底，但实际失效很常见：
- 闭包内自己
try/catch了异常却没throw出去，框架收不到未捕获异常，就不会触发回滚 - 项目启用了自定义
set_error_handler或error_reporting被设为0，导致底层异常拦截失效 - 闭包里调用了
exit、die或dd()，PHP 进程直接终止，finally块没执行，事务卡在 “active” 状态 - 闭包返回值被忽略，但内部已执行
Db::commit()（比如手动调了），后续异常也救不回来
在事件回调中开启事务，必须手动配对 commit/rollback
比如监听 model.after_insert 后要联动更新另一张表，又想保证原子性，就不能只写 Db::startTrans() 就完事：
- 必须在事件回调里完整包裹
try→ 执行 DB 操作 →commit/catch→rollback - 不能依赖模型自身的 save() 成败来决定是否回滚：save() 报唯一索引冲突（
SQLSTATE[23000]: Integrity constraint violation）只是抛异常，不会自动 rollback - catch 必须是
Throwable，不是仅Exception—— PDO 的某些错误是Error子类，会被漏掉 - 如果事件里混用
Db::name()和模型实例（如UserModel::create()），需确认它们走的是同一个 PDO 连接，否则事务隔离，rollback 只影响其中一部分
测试事件内事务回滚，别用 dd() 中断流程
本地调试时习惯在事件回调中间加 dd('here') 看状态，这会导致：
- PDO 连接未释放，事务长期处于 active 状态
- 连接池复用该连接时，下次请求报
There is no active transaction或直接失败 - 数据库里能看到“半截数据”，但查不到活跃事务，排查困难
替代做法：
– 改用 Log::info() 记录关键变量和 SQL（Db::getLastSql()）
– 需验证是否真没落库，另起一个无事务连接去查（如 Db::connect(['deploy' => 0])->table('xxx')->find()）
– 测试完立刻执行 Db::rollback() 清理，而不是靠脚本结束“自动释放”
最易被忽略的一点：事务回滚只作用于当前连接上的操作，事件可能被多次触发、跨请求、甚至异步队列中执行——这些场景下，Db::transaction() 闭包或 startTrans() 都只对当次执行有效，别想让它跨生命周期兜底。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
