分页查询需手动计算 offset 和 limit，正确公式为 offset = (page - 1) * size；page 通常从 1 开始，size 应校验上限；大 offset 易致全表扫描，需业务限制页码或引入分页优化方案。
分页查询必须手动计算 offset 和 limit
GORM 本身不提供内置的分页函数，Paginate 这类方法只存在于第三方扩展（如 gorm/pagination），官方库默认只支持原生的 Limit 和 Offset。直接写 db.Limit(10).Offset(20) 是最稳妥、兼容性最好的方式。
常见错误是把页码当成 offset：第 3 页（每页 10 条）的 offset 应该是 (3-1)*10 = 20，不是 3*10。漏掉减 1 就会跳过第一页数据。
- offset = (page - 1) * size，务必检查 page 是否从 1 开始（前端传来的页码通常如此）
- size 建议做上限校验，比如限制最大
size ，防 SQL 注入或拖垮数据库 - 用
Count查总数时，记得复用相同查询条件（Where、Joins 等），否则总数和分页结果对不上
Count 查询要避免重复构建条件
分页常需返回总条数，但很多人在 Count 前忘记复制完整查询链，导致总数不准。例如：
db.Where("status = ?", "active").Find(&users).Limit(size).Offset(offset)
db.Where("status = ?", "active").Count(&total) // ✅ 正确：条件一致
db.Count(&total) // ❌ 错误：没带 Where，统计全表更安全的做法是先构建基础查询对象：
query := db.Where("status = ?", "active")
query.Find(&users).Limit(size).Offset(offset)
query.Count(&total)- 不能用
query.Session(...)或query.Table(...)后再调Count，部分 GORM 版本下会丢失条件 - 涉及
Joins的场景，Count可能需要Count("DISTINCT xxx.id")避免关联膨胀 - MySQL 8+ 支持窗口函数，可考虑用
SELECT *, COUNT(*) OVER() AS total一次查出数据+总数，但 GORM 不自动支持，得手写Raw
使用 gorm/pagination 扩展要小心版本兼容
第三方包 github.com/lestrrat-go/gorm-pagination 或更常见的 github.com/gookit/goutil/dbs/gormutil 提供了 Paginate 方法，但它们不是 GORM 官方维护，容易与新版 GORM（v2.0+）冲突。
典型报错：cannot use db (type *gorm.DB) as type *gorm.DB in argument to pagination.Paginate——本质是类型别名不匹配（GORM v2 把 *gorm.DB 改为接口，而老扩展仍依赖结构体指针）。
- 如果坚持用扩展，确认其
go.mod依赖的是gorm.io/gorm v1.25.5还是v2.x - v2 推荐自己封装一个简单分页函数，5 行就能搞定，比引入不稳定扩展更可控
- 某些扩展会静默忽略
Order或Preload，查出来顺序乱或关联字段为空，必须实测验证
性能敏感场景慎用 OFFSET
当 OFFSET 很大（比如第 10000 页），MySQL / PostgreSQL 仍需扫描前面所有行，响应明显变慢。这不是 GORM 的问题，而是 SQL 分页通病。
替代方案不是换 ORM，而是换策略：
- 用游标分页（cursor-based）：基于上一页最后一条记录的
id或created_at做条件，如WHERE id > ? ORDER BY id LIMIT 10 - 对高频翻页场景，预生成分页映射表，或用 Elasticsearch 等专门做分页加速
- 业务上限制最大页码（如只允许查前 200 页），前端禁用“跳转到末页”按钮
offset 越大，数据库越可能放弃索引走全表扫描，这个临界点取决于数据分布和索引设计，没法靠改 GORM 写法绕过。
