thinkphp事件中必须使用db::transaction()闭包方式处理事务，因其强制复用同一pdo连接，确保模型与db操作事务一致性；手动starttrans()/commit()/rollback()易因连接不一致导致事务失效或静默失败。
ThinkPHP 事件里不能直接用 Db::startTrans() + commit()/rollback() 做事务，因为事件回调执行时可能已脱离原始请求上下文，连接实例不可控，事务极易失效或作用于错误连接。
事件中事务必须用 Db::transaction() 闭包写法
事件（比如 after_insert、before_update 或自定义事件）触发时机不固定，常在模型保存后、队列任务中、或异步钩子里执行。此时手动事务的 startTrans() 很可能初始化了一个新连接，而后续 Db::table() 或模型操作走的是另一个连接 —— 导致 commit() 无声失败，或 rollback() 对空事务调用报 There is no active transaction。
-
Db::transaction()强制复用同一 PDO 实例，从进入闭包那一刻起就绑定连接，无论里面混用多少模型或Db::table()都能保证一致性 - 异常未被捕获时自动回滚，不用手写
try/catch，避免漏写rollback() - 即使事件被多次触发（如批量导入触发 100 次
after_insert），每个闭包都是独立事务，互不影响
混用模型和 Db 查询时事务仍会断开
事件里常见写法是：先用 User::create() 插入用户，再用 Db::table('log')->insert() 记日志。这看似顺理成章，但 TP 5.1+ 中两者默认使用不同连接对象 —— 尤其启用了读写分离或连接池时，User 走写库连接 A，log 表可能被路由到连接 B，事务完全失效。
- 闭包内所有 DB 操作（包括模型
save()、delete()、Db::name()、Db::table()）都共享同一个连接 - 不要在闭包外提前调
Db::connect()或new UserModel()再传进去，那会绕过连接绑定机制 - 如果必须复用已有模型实例，确保它来自闭包内创建，而非外部注入
Db::transaction() 的隔离级别参数别乱传
第二个参数可传 Db::TRANSACTION_READ_COMMITTED 这类常量，但 MySQL 实际只认 REPEATABLE READ（默认）和 SERIALIZABLE，其他值会被 PDO 忽略且不报错。
- 传字符串如
'READ COMMITTED'不生效，降级为默认级别，现场很难察觉 - 高并发下盲目设
SERIALIZABLE会极大增加锁冲突概率，反而引发死锁 - 超时靠 MySQL 的
wait_timeout控制，不是 PHP 层能中断的；长事务（>30s）建议拆分或加监控告警
真正容易被忽略的是：事件里的事务闭包不能包含 exit、die 或未捕获的致命错误（如 undefined function），否则 PDO 连接不会正常释放，可能导致连接池耗尽。务必让异常穿透闭包，交由 Db::transaction() 自动处理。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
