db.Statement.InTransaction()是唯一可靠判断当前gorm.DB是否处于事务中的方式，它直接读取底层*sql.Tx状态，不受并发、中间件或变量误用影响，嵌套SavePoint下仍准确返回true。
db.Statement.InTransaction() 是唯一可靠判断方式
别依赖 db.Statement.ConnPool == nil 或手动维护标记位——前者在 GORM v2.2+ 已不可靠，后者容易被并发或中间件覆盖。真正能反映当前 *gorm.DB 实例是否绑定了活跃事务的，只有 db.Statement.InTransaction()，它直接读取底层 *sql.Tx 的状态。
为什么不能用 tx == db 来判断
事务对象不是“开关”，而是独立实例：db.Transaction(...) 或 db.Begin() 返回的是全新 *gorm.DB，和原始 db 地址不同、连接池引用也不同。你拿 tx == db 比较永远是 false，毫无意义。
-
db是普通连接池实例，tx是带*sql.Tx的封装体，二者类型一致但语义隔离 - 即使在
db.Transaction闭包里，db本身仍为非事务状态，只有传入的tx才是事务上下文 - 混用
db.Create()和tx.Create()是常见数据不一致根源，靠地址比较发现不了
实际调试中怎么快速验证
加一行日志即可，无需额外依赖：
log.Printf("in tx? %v", db.Statement.InTransaction())
- 返回
true：说明当前db实例已绑定有效*sql.Tx，后续Create/Update等操作会走事务路径 - 返回
false：哪怕你在db.Transaction闭包里，如果误用了全局db变量（而非参数传入的tx），这里就是false - 注意：该方法不检查事务是否已提交或回滚，只看底层
*sql.Tx是否非 nil 且未关闭
嵌套 SavePoint 场景下依然有效
调用 tx.SavePoint("sp1") 后，新返回的 spTx 仍是事务上下文，spTx.Statement.InTransaction() 仍返回 true。它不区分是顶层事务还是保存点，只认有没有活跃的 *sql.Tx。
- SavePoint 不创建新事务，只是在同一条数据库连接上打标记，所以事务状态保持不变
- 若你看到
InTransaction() == false却以为自己在事务里，大概率是函数参数传错了对象，比如把db当成tx传了进去 - 该方法在 MySQL/PostgreSQL/SQLite 上行为一致，无方言差异
事务上下文不是隐式传播的，InTransaction() 返回值就是当前实例的“最终解释权”。任何想绕过它的推断（比如查 context、看变量名、数函数调用深度）都会在复杂中间件或异步流程里失效。
