GORM报表分页必须手动实现Limit+Offset并独立执行总数查询，因第三方Paginate封装无法保证Count与主查询条件完全一致，且易忽略排序稳定性与参数陷阱。
GORM 没有内置分页方法，报表场景下必须手写 Limit + Offset，且总数查询不能和列表共用同一个 *gorm.DB 实例
为什么不能直接用第三方 Paginate 封装
所谓「自动分页」封装（比如 github.com/lestrrat-go/paginate 或社区自研的 Paginate 方法）本质只是帮你算 Offset 和拼 Count SQL，但隐藏了关键约束：
- 它无法保证
Count查询和主查询的 WHERE 条件完全一致（尤其带 JOIN、子查询、动态条件时极易漏字段或错别名） - 多数封装默认不校验
page和page_size，前端传page_size=10000会直接打爆数据库连接池 - 报表常需导出全量，而封装往往强制走分页逻辑，导致
ExportAll和GetPage两套路径难以复用同一份查询构建逻辑
Limit 和 Offset 的顺序与参数陷阱
在 GORM v2 中，Offset().Limit() 和 Limit().Offset() 都能生成合法 SQL，但行为不等价：
-
Offset(10).Limit(20)→SELECT ... LIMIT 20 OFFSET 10（正确：跳过前 10 条，取 20 条） -
Limit(20).Offset(10)→ 在某些驱动（如 SQLite）下可能被解释为「先取 20 条，再从中跳过 10 条」，结果只有 10 条 -
Offset参数必须是非负整数；传负数会 panic，传 0 是合法的（从第 1 条开始） -
Limit(0)表示「不限制条数」，等价于不加LIMIT，不是「取 0 条」
报表分页必须显式 Order，否则数据错乱
MySQL/PostgreSQL 对无序 OFFSET 的行为不保证稳定——同一查询多次执行，行序可能不同，导致：
- 第 1 页出现 ID=5,8,12，第 2 页又出现 ID=5（重复）
- ID=10 永远查不到（漏数据）
解决方式只有一条：所有分页查询必须带确定性排序，例如：
db.Order("created_at DESC, id DESC").Offset((page-1)*size).Limit(size)
注意：不要用 ORDER BY RAND()，也不要依赖数据库默认主键顺序（如没显式 ORDER BY id，InnoDB 可能按聚簇索引物理顺序返回，但该顺序受插入/删除影响）
总数查询必须独立执行，且避免复用链式 DB 实例
这是报表分页最容易翻车的地方。错误写法：
rows := db.Where("status = ?", 1).Order("id ASC")
count := rows.Count(&total) // ❌ 错误：Count() 会复用前面的 Order 和 Where，但 COUNT(*) 不需要 ORDER
list := rows.Offset(...).Limit(...).Find(&items) // ❌ 错误：rows 已被 Count() 消费，Find 可能 panic 或返回空
正确做法是拆成两个独立查询：
// 总数：只保留过滤条件，去掉 Order、Limit、Offset、Select 等干扰项
var total int64
db.Model(&Report{}).Where("status = ?", 1).Count(&total)
// 列表：重新构造查询，显式加 Order
var items []Report
db.Where("status = ?", 1).Order("created_at DESC, id DESC").Offset((page-1)*size).Limit(size).Find(&items)
关键点：
-
Model(&T{})是安全起点，它重置了查询上下文，不会继承之前链式调用的副作用 - 如果 WHERE 条件复杂（含 JOIN），
Count必须用Session(&gorm.Session{DryRun: true})先调试生成的 COUNT SQL 是否合理 - 报表常需缓存总数（如每小时更新一次），避免高频 COUNT 压垮主库
报表分页真正的难点不在 Limit/Offset 写法，而在「总数一致性」和「排序稳定性」——这两个点一旦忽略，用户刷几次页面就发现数据对不上，而问题往往出现在上线后几周才暴露。
