GORM分页须手动组合Limit和Offset：Offset传(page-1)*pageSize（如第2页每页10条则Offset(10)），严禁将page直接作Offset；必须校验page≥1、pageSize∈[1,100]，且Order显式排序、Count独立执行。
分页参数怎么传给 Limit 和 Offset
GORM 本身不提供内置的「分页方法」，得靠手动组合 Limit 和 Offset。传参时最容易错的是把页码当偏移量用——比如第 2 页、每页 10 条，Offset 应该是 10（不是 2），计算公式是 (page - 1) * pageSize。
常见错误现象：Offset(2).Limit(10) 实际查的是第 3 条开始的 10 条，不是第 2 页；或者前端传 page=0 导致负数偏移，GORM 会静默忽略或报错（取决于数据库驱动）。
- 始终校验
page > 0且pageSize > 0 && pageSize （防恶意大页） - 用
int64接收分页参数，避免整型溢出（尤其Offset累积大时） - MySQL 下
Offset过大会拖慢查询，后面会提优化方案
如何安全获取总条数（Count）
分页必须知道总记录数才能算页数，但 GORM 的 Count 和主查询不共享条件，容易漏写 Where 或 Joins，导致总数不准。
典型场景：带关联查询的分页，比如查用户列表并预加载其部门信息。如果只对 User 模型调 Count，没加 Joins("Department") 和对应 Where，总数可能比实际多（因笛卡尔积未被过滤）或少（因 JOIN 条件缺失）。
- 把查询逻辑抽成函数，复用同一个
*gorm.DB链式调用，再分别接Count和Find - 不要在
Count前调Limit/Offset，否则结果为 0 或错乱 - PostgreSQL 支持
SELECT COUNT(*) OVER()，可单次查询返回数据+总数，但 GORM 8.x 尚未原生支持，需手写Raw
用 Scopes 封装分页逻辑是否靠谱
可以封装，但要注意作用域污染和链式中断。GORM 的 Scope 是函数类型，接收 *gorm.DB 并返回 *gorm.DB，但它无法自动处理 Count —— 你封装的分页 scope 只影响 Find，不自动帮你算总数。
一个常见坑是：把分页逻辑写进 scope，然后在 service 层先调 Count 再调 Find，但两次调用没共用同一份查询条件（比如中间加了新 Where），导致总数和数据不一致。
- 推荐用结构体封装分页参数和结果，例如
type PageResult struct { Data interface{}; Total int64; Page, PageSize int } - scope 只做「条件拼装」，分页和计数逻辑放在调用方统一控制
- 避免在 scope 里调
Limit/Offset，除非你确定它只用于最终查询（不能复用于 Count）
性能差的 OFFSET 怎么绕过
当 OFFSET 超过几万行，MySQL 执行会明显变慢，因为要扫描并丢弃前面所有行。这不是 GORM 的问题，而是 SQL 本身的瓶颈。
真正可行的优化不是换 ORM，而是换分页策略：用「游标分页（cursor-based）」替代「页码分页（offset-based）」。核心是利用有序字段（如 id 或 created_at）做边界条件，例如上一页最后一条记录 id = 12345，下一页就查 WHERE id > 12345 ORDER BY id LIMIT 10。
- 游标分页无法跳转任意页，但适合无限滚动等场景，且性能稳定
- GORM 完全支持这种写法：
db.Where("id > ?", lastID).Order("id ASC").Limit(10).Find(&users) - 注意时间字段做游标时要处理重复值（加
id作为第二排序字段）
分页最麻烦的从来不是写几行 Limit 和 Offset，而是保证总数准确、条件一致、性能可控——这些地方一松懈，线上就容易查慢或翻页错乱。
