Scopes 是接收并返回 *gorm.DB 的函数，用于链式构建查询；需严格签名、避免提前执行、显式传参、控制分页参数、顺序影响SQL逻辑、事务中注意句柄、不处理错误。
Scopes 就是带参数的 func(*gorm.DB) *gorm.DB
它不是魔法，就是个普通函数签名——接收一个 *gorm.DB，返回一个修改后的 *gorm.DB。所有条件拼接、分页、表切换，都靠它返回的新实例完成链式调用。
- 写错签名（比如漏了返回值、参数类型不对）会导致编译失败或静默失效，GORM 不会报错，但
Scopes()里啥都没发生 - 不能在 Scope 函数里直接
Find()或Exec()，那会提前触发查询，破坏链式逻辑 - 闭包传参必须用「返回函数的函数」形式，比如
AgeScope(25)返回的是func(*gorm.DB) *gorm.DB，不是直接执行
分页 Scope 别硬塞 *http.Request，改用显式参数
网上很多示例用 Paginate(r *http.Request)，看着方便，实际埋雷：耦合 HTTP 层、无法单元测试、没法复用于 CLI 或定时任务场景。
- 推荐写法：
Paginate(page, pageSize int)，调用时从请求里取值再传入，比如db.Scopes(Paginate(page, pageSize)).Find(&users) -
pageSize必须做上限控制（如最大 100），否则恶意请求可能拖垮数据库；page小于 1 时默认设为 1，避免负偏移 - 别在 Scope 里做
strconv.Atoi—— 类型转换应该在 controller 层完成，Scope 只管构建查询
多个 Scope 组合时，顺序影响 SQL 执行逻辑
db.Scopes(AmountGreaterThan1000, PaidWithCreditCard).Find(&orders) 等价于 WHERE amount > 1000 AND pay_mode = 'card'，但如果你的某个 Scope 里用了 Table() 或 Joins()，顺序就关键了。
-
Table()类 Scope 应该放在最前面，否则后续Where()可能作用在错误的表上 - 带
Order()的 Scope 放最后，避免被后续其他 Scope 的Order()覆盖（GORM 不合并 Order，只保留最后一个） - 权限类 Scope（如
OnlyOwnRecords()）建议放第一个，尽早过滤数据量，减少中间计算开销
事务里用 Scopes 得小心句柄传递
直接在 Transaction() 回调里调 tx.Scopes(...).Find() 没问题，但如果你把 Scope 抽成变量再传进去，就容易误用 db 而非 tx。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
scopes := []func(*gorm.DB)*gorm.DB{PaidWithCreditCard}，然后在事务里tx.Scopes(scopes...)—— 看似对，但 Scope 函数内部仍可能隐式依赖全局db - 安全做法：所有涉及事务的 Scope，要么在回调内定义，要么显式接收
*gorm.DB参数并只操作它，不碰包级变量 - 调试时加
LogMode(true)看生成的 SQL，确认 WHERE 条件和表名是否符合预期，尤其跨库或动态表场景
Scopes 最容易被忽略的点，其实是「它不处理错误」——Scopes() 永远返回 *gorm.DB，哪怕你传了个 nil 函数，也不会 panic。查不到数据、条件拼错、字段名写错，全得靠日志和 SQL 验证来兜底。
