Scopes函数签名必须为func(gorm.DB) gorm.DB，多参、少、返回error或nil均导致编译失败或静默失效；正确用闭包封装动态参数，分页Scope中Count需新建Session或Model避免状态污染，Paginate须置于Scope链末尾，page/limit必为int并校验边界，Order必须显式声明且含索引字段。
Scopes函数签名必须严格是 func(*gorm.DB) *gorm.DB
这不是约定，是GORM硬性要求。任何多一个参数、少一个*、返回error或nil的函数，传给db.Scopes()都会编译失败或静默失效。
常见错误写法：func WithStatus(db *gorm.DB, status string) *gorm.DB——GORM根本不认这种签名。
正确解法只能用闭包封装动态参数：
func WithStatus(status string) func(*gorm.DB) *gorm.DB {
return func(db *gorm.DB) *gorm.DB {
if status == "" {
return db
}
return db.Where("status = ?", status)
}
}
调用时写成：db.Scopes(WithStatus("active")).Find(&users)。
立即学习“go语言免费学习笔记（深入）”；
闭包里做空值判断很关键，否则WHERE status = ''可能命中意外数据，或让数据库跳过索引。
分页Scope里别直接用原始db查Total
在Paginate(page, limit int) func(*gorm.DB) *gorm.DB里调db.Count()是典型陷阱：它会污染当前db实例的状态，导致后续Find()出错——比如Count()悄悄加了GROUP BY，Find()就查不到数据；或者Count()被LIMIT干扰，总数不准。
安全做法只有两种：
- 用
db.Session(&gorm.Session{NewDB: true})新建干净实例再查Count - 显式用
db.Model(&User{}).Where(...).Count(&total)，不依赖链式上下文
如果组合了多个Scope（比如StatusScope和DateRangeScope），必须确保Paginate放在Scopes()调用链的最后，否则Offset/Limit可能被前面的Where或Joins干扰。
分页参数必须校验并设边界，不能信前端传的值
page和limit字段必须是*int类型，而不是int。因为Gin的ShouldBindQuery对非指针字段绑定失败时会静默设为0，而page=0会导致Offset(-limit)，GORM直接panic；limit=0会让Limit(0)失效，查出全表。
在Scope闭包里要主动处理：
if p.Page == nil || *p.Pageif p.Limit == nil || *p.Limit 100 { *p.Limit = 20 }
硬编码上限（比如max=100）不是保守，是防DDoS——恶意请求?limit=100000可能拖垮数据库。
Order必须显式声明，否则分页结果不稳定
GORM不做任何行序保证。没有Order的Offset/Limit查询，在主从复制、MVCC或并发写入下，两次执行可能返回不同记录——漏数据或重复，这不是bug，是数据库行为。
错误写法：db.Scopes(Paginate(2, 20)).Find(&users)（没Order）。
正确写法：db.Order("id ASC").Scopes(Paginate(2, 20)).Find(&users)，且id字段必须有索引。
业务上按时间排序？用created_at DESC，但注意created_at字段如果有大量相同值（比如批量插入），仍需加二级排序字段（如id DESC）来保序。
