分页参数必须校验并截断，pagenum≤0时强制设为1，pagesize超上限（如100）则截断；count查询须隔离db实例，否则total≤limit；paginate scope必须置于scopes组合末尾，且order必须显式声明（如order("id asc")），大数据量应改用游标分页。
分页参数必须校验并截断，不能直接透传给Limit/Offset
Go微服务里前端常传 page=1、page_size=20，但GORM不拦非法值：传 page=0 会导致 Offset(-20) 直接 panic；传 page_size=10000 可能拖垮数据库。Gin 的 c.ShouldBindQuery(&p) 对非指针字段绑定失败时会静默设为零值，所以 PageNum 和 PageSize 必须声明为 *int，才能在 Scope 内安全判断是否为 nil 并填充默认值。
实际处理建议：
-
PageNum小于等于 0 时强制设为 1，不返回错误（用户点错页码不是服务端该拒掉的场景） -
PageSize超过上限（如 100）就截断，比如if *p.Size > 100 { *p.Size = 100 } - 用
strconv.ParseInt(c.Query("page"), 10, 64)替代绑定，可提前判空和捕获格式错误
Count查询必须隔离DB实例，否则结果永远≤Limit
常见错误是写 db.Where(...).Limit(size).Offset(offset).Count(&total)——这算出来的是“当前页条数”，不是总记录数。因为 Count() 复用了链上已有的 LIMIT 和 OFFSET，total 永远 ≤ size。微服务中这个错误会导致前端页码控件失效或显示“共 0 页”。
正确做法是切断链式污染：
- 用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total)，靠NewDB: true新建干净实例 - 更稳妥的是显式指定模型和条件：
db.Model(&User{}).Where("status = ?", "active").Count(&total) - 复杂 JOIN 场景下，手写子查询更可靠：
db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE u.status = ?) AS t", "active").Scan(&total)
分页Scope必须放在组合末尾，且Order必须显式声明
如果用多个 Scopes 组合查询（比如 StatusScope + DateRangeScope + Paginate(p)），Paginate(p) 必须放在最后。否则前面的 Scope 可能已调用过 Limit 或 Offset，导致分页逻辑被覆盖或 panic。
另外，GORM 不保证无序查询的行序稳定。同一分页请求执行两次，可能漏数据或重复——这不是 bug，是 MySQL/PostgreSQL 的 MVCC 和并发写入行为决定的。微服务高可用场景下，这点极易引发数据一致性投诉。
务必显式加 Order：
- 优先用主键排序：
db.Order("id ASC")，确保有索引 - 业务需按时间分页时，用
db.Order("created_at DESC, id DESC")，避免同秒多条记录导致顺序不可控 - 绝对不要省略
Order去“优化性能”，这是拿数据正确性换毫秒延迟
大数据量必须考虑游标分页，Offset/Limit不是银弹
当单表数据超百万，OFFSET 越大越慢：MySQL 得扫描并丢弃前 N 行。微服务里查第 10000 页（每页 20 条）可能耗时数秒甚至超时。这不是 GORM 能优化的，是 SQL 层面的结构性瓶颈。
游标分页更适合微服务高频列表场景：
- 前端传上一页最后一条的
created_at和id，后端查WHERE created_at - 要求排序字段（如
created_at, id）有联合索引，否则照样慢 - 牺牲“跳转任意页”的能力，换来稳定低延迟和可扩展性
真正难的不是写代码，而是让团队接受“页码不是必需品”——尤其当产品坚持要“跳到第 500 页”时，得提前对齐技术边界。
