DryRun模式不显示BEGIN/COMMIT/ROLLBACK，因其仅捕获实际执行的SQL语句，而事务控制语句由驱动在连接层隐式处理，GORM不将其纳入SQL构建流程。
DryRun 模式不能直接用于事务调试，必须配合显式事务对象（*gorm.DB）单独启用，否则生成的 SQL 不含事务上下文，会误导判断。
为什么 DryRun 默认不显示 BEGIN/COMMIT/ROLLBACK
DryRun 模式只捕获「实际执行的 SQL 语句」，而 db.Begin()、tx.Commit()、tx.Rollback() 这些调用本身不生成 SQL，它们操作的是数据库连接状态。所以即使你在事务内调用 tx.Where(...).Update(...)，DryRun 只打印 UPDATE 语句，不会附带事务边界信息。
- 事务控制语句（BEGIN/COMMIT/ROLLBACK）由数据库驱动在连接层隐式处理，GORM 不将其纳入 SQL 构建流程
- 如果你用
db.Session(&gorm.Session{DryRun: true})启动 DryRun，但后续没用该 session 对象做操作，实际走的仍是普通 DB 实例，SQL 不会被捕获 - 隐式事务（
db.Transaction(func(tx *gorm.DB) error {...})）中无法在外部拿到tx对象来设 DryRun，函数体内部也无法修改传入的tx配置
正确开启 DryRun 调试事务 SQL 的两种方式
核心原则：所有 CRUD 操作必须通过同一个开启了 DryRun 的 *gorm.DB 实例执行，且该实例需是事务对象（tx），不能是根 db。
- 显式事务 + DryRun Session：先
tx := db.Session(&gorm.Session{DryRun: true}).Begin()，再对tx执行查询/更新，最后tx.Rollback()（不用 Commit） - 手动构造事务上下文：用
db.Session(&gorm.Session{DryRun: true})获取 dry-run 实例后，调用.Exec("BEGIN")、.Exec("COMMIT")等模拟事务边界（仅限调试，不推荐生产） - 避免写法：
db.DryRun().Begin()——DryRun()返回新实例，但Begin()在原实例上执行，两者错配
ToSQL 方法比 DryRun 更适合事务逻辑验证
ToSQL 是 GORM v1.24+ 提供的轻量替代方案，它不依赖 DB 连接，纯构建 SQL 字符串，且能保留链式调用中的条件逻辑，对事务内多步操作更可控。
-
db.Where("name = ?", "Tom").ToSQL(&User{})返回"SELECT * FROM `users` WHERE name = ?"，参数未插值，安全可读 - 事务中每一步都可独立
ToSQL：比如tx.Where(...).Updates(...).ToSQL(&User{})，确认 WHERE 条件和 SET 字段是否符合预期 - 注意：
ToSQL不展开关联预加载（Preload）、不处理钩子（Hooks）、不模拟软删除字段过滤，复杂场景仍需结合 DryRun 实测
容易被忽略的 DryRun 事务陷阱
DryRun 输出看似“干净”，但几个关键点常导致线上行为与预期不符：
- SavePoint 名称默认是随机 UUID，
tx.SavePoint("sp1")和tx.RollbackTo("sp1")在 DryRun 下无法验证名称是否匹配，必须实跑测试 - 嵌套事务（
tx.Session(&gorm.Session{AllowGlobalUpdate: true})）中 AllowGlobalUpdate 等配置项不反映在 SQL 中，DryRun 看不到权限放宽效果 - 使用
db.Clauses(clause.Locking{Strength: "UPDATE"})加锁时，DryRun 会输出FOR UPDATE，但不同数据库（MySQL vs PostgreSQL）对锁语法兼容性不同，不能只信 DryRun 输出 - 事务中若混用
db.Raw("...").Scan()，DryRun 不捕获该 SQL，除非你对db.Session(...).Raw(...)显式启用 DryRun
真正要验证事务原子性、隔离级别、锁等待行为，DryRun 只能帮你卡住 SQL 生成这第一关；下一步必须在本地启一个真实数据库，用 tx.Rollback() 结束事务并观察日志或锁表状态。
