事务中复用Scopes会丢失上下文，因Scope不感知事务且可能复用已提交的事务实例，导致panic或数据不一致；所有Scope须接收并返回*gorm.DB，Preload/Joins需共享同一事务，分页需隔离Count与Find实例，顺序应先过滤再排序分页。
事务中直接复用 Scopes 会丢失事务上下文
Scopes 函数本身不感知事务，它只是链式修改 *gorm.DB 的 Statement。如果你在事务外定义了一个 Scope，再传入事务内调用，它会正常执行；但反过来——在事务内定义 Scope 并试图复用到其他事务或非事务 DB 实例上——就可能出问题：Scope 返回的 *gorm.DB 仍指向原始事务对象，而事务一旦提交/回滚，该实例就不可再用。
常见错误现象：panic: invalid transaction 或查到旧数据（事务未生效）；或者多个并发请求共用一个事务 Scope 导致条件错乱。
- 永远不要在事务闭包里定义 Scope 函数（比如把
func() func(*gorm.DB) *gorm.DB写在db.Transaction(func(tx *gorm.DB) error { ... })里面） - 所有 Scope 必须接收
*gorm.DB并返回*gorm.DB，且内部不能假设传入 db 是事务型还是普通型 - 如果 Scope 里用了
Preload或Joins，确保它们也运行在同一个事务上下文中——GORM 默认会继承父 db 的事务，但若你在 Scope 里手动调用db.Session()且没传Context或Transaction，就会脱离事务
带 Preload 的 Scope 在事务中必须显式传递事务实例
Preload 和 Joins 不是纯条件修饰，它们会触发额外查询。在事务中，这些关联查询必须和主查询共享同一事务，否则会出现“主表已更新、关联表未更新”的数据不一致。
错误写法：func WithOrderItems(db *gorm.DB) *gorm.DB { return db.Preload("Items") } —— 这个函数在事务中调用时，Preload 默认走的是当前 db 的事务，看似没问题；但一旦你后续对这个 db 做了 Session(&gorm.Session{NewDB: true})，就断开了事务链。
- 稳妥做法：Scope 内不新建 Session，所有操作基于输入的
db；如需隔离（比如分页 Count），用db.Session(&gorm.Session{NewDB: true, Context: db.Statement.Context})显式继承上下文 - 测试时加
DryRun: true看生成 SQL 是否含BEGIN/COMMIT上下文，或是否出现多条独立 SELECT（说明 Preload 脱离了事务） - 高并发场景下，避免在 Scope 中做
Preload+ 复杂条件组合，容易触发 N+1；优先用Joins+Select拉平字段
事务内分页 Scope 必须隔离 Count 和 Find 的 DB 实例
这是最容易踩的坑：在事务里调用封装好的分页 Scope（比如 Paginate(page)），如果它内部用的是同一个 *gorm.DB 实例去跑 Count() 和 Find()，就会因链式污染导致 Count() 带上 LIMIT 或丢掉 ORDER BY，进而算错总数或漏数据。
更麻烦的是，事务中 Count() 若被干扰，还可能让后续 Find() 锁住错误范围的行（尤其用了 FOR UPDATE）。
- 分页 Scope 内部必须用
db.Session(&gorm.Session{NewDB: true, Context: db.Statement.Context})创建新实例做Count() - 或者更明确地：用
db.Model(&T{}).Where(...).Count(&total)，不依赖当前链状态 - 务必确认
Page结构体中Current和Size是*int类型，否则 GinShouldBindQuery绑定失败时设为 0，Offset(-size)直接 panic，事务中断
事务 Scope 组合顺序影响锁范围和性能
GORM 的 Scope 执行顺序就是调用顺序，而 WHERE 条件、ORDER BY、LIMIT 的位置直接影响数据库能否命中索引、是否需要临时排序、以及 FOR UPDATE 锁住多少行。
例如：你写了 db.Transaction(...).Scopes(WithStatusActive, WithTenantID(tenantID), Paginate(p)).Order("created_at DESC").Find(&orders)，但如果 Paginate Scope 把 Limit 放在 Order 前面（它不该这么做），MySQL 就无法用索引优化排序，还可能锁住全表。
- 所有事务相关 Scope（如租户过滤、软删除、状态检查）必须放在分页和排序之前，确保 WHERE 先缩小结果集
-
Order必须显式写在Scopes之后、Find之前，且字段要有索引；不要指望 Scope 自动加 Order - 如果业务要求按时间分页且防重复，用
Order("created_at DESC, id DESC")，避免高并发下created_at相同导致分页偏移错乱
事务里用 Scopes 最难缠的不是语法，而是状态传递的隐式性——你以为传了个函数就万事大吉，其实 db.Statement 里藏着事务 ID、上下文、预处理句柄、甚至缓存的 prepared statement。任何一次 NewDB: true 或 WithContext 遗漏，都可能让 Scope 在事务里“半身不遂”。
