gorm未内置paginate方法是因分页逻辑高度依赖业务场景，官方刻意回避通用封装；必须手动组合offset/limit、显式排序、独立查总数，并在高偏移或高频写入时改用游标分页。
为什么 GORM 没有内置 Paginate 方法
GORM 官方从 v1 到 v2 始终没把分页做成原生方法，不是遗漏，而是刻意回避。它认为分页逻辑高度依赖业务场景：是否要查总数、是否允许前端控制 page_size、要不要兼容游标分页、关联数据怎么加载——这些没法用一个通用接口覆盖。所以 Paginate 一定是第三方封装，比如 github.com/joshbetz/pagination 或自行实现的 Scopes 函数。直接调用它，等于把校验、排序、计数、错误兜底等责任全交给插件，而插件往往不处理 page=0 或 page_size=-1 这类输入，一跑就 panic。
Offset 和 Limit 必须手动组合，且顺序不能错
这是最稳妥、兼容性最强的做法，所有 GORM 版本都支持。关键点不在“会不会写”，而在“什么时候写错”：
-
Offset必须在Limit之前调用（即使 v2 允许互换，但老项目或中间件里复用链式 DB 实例时，顺序错会导致 Offset 被忽略） -
Offset((page - 1) * pageSize)中，page必须 ≥ 1，否则Offset(-10)直接 panic；pageSize必须 > 0，否则Limit(0)在 SQLite 下返回全表，在 MySQL 下可能被优化掉，行为不一致 - 必须显式加
Order，比如Order("id ASC")，否则数据库无序返回，翻页时数据重复或丢失 - 总数查询必须单独执行：
db.Model(&User{}).Count(&total)，不能复用带Where或Preload的主查询链，否则条件污染导致总数不准
用 Scopes 封装分页时，别复用原始 *gorm.DB
很多人写 func Page(page, size int) func(*gorm.DB) *gorm.DB，然后直接传入 db.Scopes(Page(p, s)).Find(&users)，这看似干净，实则危险：
- 如果原始
db已带Where("status = ?", 1)，而分页函数里又调了Count()，那总数统计也会带上这个条件——但你可能想统计全部状态的总数 - 正确做法是：在 Scope 内部新建一个干净的
*gorm.DB实例（如db.Session(&gorm.Session{NewDB: true})）做 Count，再用原始 db 做 Find - 更安全的写法是把 Count 和 Find 拆成两个独立调用，显式传入条件，而不是靠链式隐式继承
高偏移或高频写入场景下，Offset 分页必须放弃
当 Offset 超过 10 万，MySQL/PostgreSQL 扫描成本剧增，响应时间从毫秒级跳到秒级；更隐蔽的问题是：用户翻页中途插入新记录，第 50 页可能漏掉刚插入的某条数据，或者重复出现上一页末尾的记录。
这时必须切到游标分页，核心是用排序字段值代替偏移量：
- 前端首次请求不带游标，后端返回第一页 + 最后一条的
id（或created_at） - 下一页请求带上
cursor=12345，后端生成WHERE id > 12345 ORDER BY id LIMIT 20 - 该 SQL 可走索引，性能稳定，且天然避免重复/丢失
- 注意：游标字段必须有索引，且不能是可空字段；若用时间戳，需加
id作为第二排序字段防重复
游标分页没法直接套用 Offset 封装，得重写查询逻辑——这也是企业级分页插件最难抽象的一环：它无法同时优雅支持两种模式。真正可靠的方案，是让业务层明确选择用哪一种，而不是插件自动“智能切换”。
