scopes 是签名固定为 func(gorm.db) gorm.db 的函数，用于链式构建查询条件；必须避免在其中执行 find 等终态方法、严格控制分页参数上限、按序组合以确保 sql 正确性，并仅操作入参 db 以保障事务安全。
Scopes 不是语法糖，也不是 ORM 魔法——它就是一串签名固定、返回 *gorm.DB 的函数，靠链式调用把条件“叠”进查询里。用对了省三行重复 Where，用错了可能查错表、漏分页、甚至在事务里掉坑。
Scope 函数必须严格满足 func(*gorm.DB) *gorm.DB 签名
GORM 只认这个签名，多一个参数、少一个星号、返回 error 或 nil 都会编译失败或静默失效。
- 错误写法：
func(db *gorm.DB, status string) *gorm.DB—— 无法传给db.Scopes() - 正确解法：用闭包封装参数，比如
OrderStatus([]string{"paid"})返回一个符合签名的函数 - 别在 Scope 里调
Find、First、Count等执行方法，否则查询提前触发，后续链式操作（如Limit）就无效了
分页 Scope 必须显式传参，且限制 pageSize 上限
把 *http.Request 塞进 Scope 是常见反模式——不仅测试难、复用差，还容易因未校验参数拖垮数据库。
- 推荐写法：
Paginate(page, pageSize int) func(*gorm.DB) *gorm.DB -
pageSize必须硬编码上限（如min(pageSize, 100)），防止恶意请求拉全表 -
page小于 1 时应归一为 1，避免Offset(-10)这类非法 SQL - 示例：
db.Scopes(Paginate(2, 20)).Find(&users)→ 对应OFFSET 20 LIMIT 20
多个 Scope 组合时，顺序影响 SQL 结构和性能
Scope 不是无序集合，而是按传入顺序依次执行。一旦某个 Scope 调用了 Table() 或 Joins()，后续 Scope 的 Where 就作用在新表上，不是原模型。
- 危险组合：
db.Scopes(TableOfYear(user, 2025), EnabledUser).Find(&users)→WHERE条件会落在users_2025表，但若EnabledUser写的是"status = ?"且该字段不在目标表，就静默失效或报错 - 安全做法：把表切换类 Scope 放最前，过滤类放后；调试时开
LogMode(true)看生成 SQL - 跨库场景更要小心：
TableOfOrg(user, "shard01")后再Joins("LEFT JOIN orders ...")，得确认orders是否也在同一库
事务中用 Scope 要传 *gorm.DB 实例，别传全局 db
事务回调里的 tx 是独立句柄，如果 Scope 函数内部隐式依赖包级变量 db，就会绕过事务，写到主库去。
- 错误写法：
scopes := []func(*gorm.DB)*gorm.DB{PaidWithCreditCard}，然后在事务里tx.Scopes(scopes)—— 看似调的是tx，但 Scope 内部若用了db.Where(...)，就还是走全局db - 正确做法：所有 Scope 函数只操作入参
db，不引用外部db；事务内直接tx.Scopes(PaidWithCreditCard, AmountGreaterThan1000).Find(...) - 更稳妥：把 Scope 定义在业务层，不暴露全局变量，靠参数传递控制数据源
db.Table() 后又接 Where，却不检查字段是否存在；或者分页没设上限，上线第一天就被扫库脚本打挂。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
