核心变量的事务安全关键在于操作是否被正确包裹在事务上下文中并确保异常真实触发回滚：错误做法是用try-catch包围整个db::transaction调用，正确做法是让异常发生在闭包内部且不被拦截；需避免跨连接、嵌套事务及读写分离导致的“假事务”，并通过强制主库查询或验证回滚效果确认事务生效。
核心变量的事务安全，关键不在“数值本身”，而在于它参与的数据库操作是否被正确包裹在事务上下文中，并确保异常能真实触达回滚机制。
让异常穿透事务闭包，别用 try-catch 吞掉错误
很多问题源于在事务闭包外加了无关的 try-catch。例如：
- 错误写法：用 try { DB::transaction(...); } catch (...) { } 包住整个事务调用——此时事务早已执行完毕并提交，catch 捕获的是事后异常，回滚已失效
- 正确做法：异常必须发生在 Db::transaction() 的闭包内部，且不被该闭包内的任何 try-catch 拦截。框架靠未捕获异常自动触发 rollback
- 若需自定义错误处理（如记录日志、返回提示），应在闭包内抛出异常，再由外层统一捕获；或改用 Db::startTrans() + Db::commit()/Db::rollback() 手动控制
避免跨连接与嵌套事务导致的“假事务”
数值变量常通过模型或查询构造器更新，但事务只对同一数据库连接生效：
- 不同数据库配置（如 'mysql_read' 和 'mysql_write'）之间无法共享事务状态，即使都更新同一个数值字段，也可能一成功一失败
- 嵌套调用 Db::transaction() 不构成真正嵌套事务（PDO 和 MySQL 均不支持），外层不会因内层异常回滚。应把所有相关操作（包括对核心数值变量的读、算、写）收进一个顶层闭包中
- 验证是否真进事务：在闭包末尾加 throw new \Exception('test')，观察数值变更是否消失——消失说明事务生效，否则检查连接复用逻辑
读写分离与隔离级别影响数值可见性
事务中更新了一个数值变量（如账户余额），紧接着查询却读不到新值，常见于两类场景：
- 开启读写分离时，update 走主库，select 被路由到从库，而从库尚未同步。解决方法：强制走主库，如 Db::master()->table('account')->where('id', 1)->value('balance')
- 单库环境下，MySQL 默认隔离级别为 REPEATABLE READ，事务快照可能不包含本事务未提交的变更。但只要使用的是同一连接（ThinkPHP/Laravel 默认复用），通常不影响；若手动调用 Db::connect() 新建连接，则脱离当前事务上下文，查不到最新值
回滚后连接状态不可信，需主动管理
事务回滚不等于连接重置。某些异常（如死锁、超时、语法错误）会让 PDO 连接进入异常状态：
- 现象：回滚后立刻执行新查询，报错 "Cannot execute queries while other unbuffered queries are active" 或连接拒绝
- 对策：在 catch 块中完成 rollback 后，建议显式关闭当前连接或切换连接池实例；高并发下可考虑使用连接健康检查或短连接策略
- 更稳妥的做法是：将核心数值操作封装为独立事务单元，失败即终止流程，不依赖“回滚后继续干活”
