go语言分页需手写limit+offset，gorm无内置paginate；必须校验参数、显式order、独立会话count、避免高offset，推荐游标分页。
Go语言分页查询必须手写 Limit + Offset，GORM 没有内置 Paginate 方法——这是最常被误用的点。你不能依赖“自动分页”，所有参数校验、排序控制、总数查询都得自己兜底。
为什么 Limit 和 Offset 必须手动组合
GORM v2 本身不提供分页封装，Paginate 是第三方插件（如 github.com/joshbetz/pagination）的方法，不是官方能力。手写最可控，也避免版本错配导致漏数据或 panic。
-
Offset接收的是“跳过多少条”，不是“第几页”；第 3 页、每页 10 条 →Offset(20)，不是Offset(3) -
Offset必须 ≥ 0，page 时直接设为 1，否则传负数会 panic（尤其 SQLite 不报错但返回空） -
Limit(0)在 MySQL 中可能忽略限制，在 SQLite 中行为未定义，务必校验pageSize > 0 - 顺序建议固定为
Offset().Limit()，虽 GORM v2 允许互换，但可读性和跨版本兼容性更稳
分页结果不稳定？大概率没加 Order
没 Order 的分页等于掷骰子：并发写入时翻页可能重复或丢失记录。数据库对无序 LIMIT 不承诺行序一致性。
- 必须显式调用
Order("id ASC")或Order("created_at DESC, id DESC")—— 单一时间字段易因重复值导致排序漂移 - 避免
Order("RAND()")，无法翻页且性能极差 - 排序字段必须有索引，否则深分页时全表扫描，
OFFSET 100000直接卡死
Count 总数查不准？别复用同一个 *gorm.DB 链
db.Where("status = ?", "active").Limit(10).Offset(20).Count(&total) 返回的 total 永远 ≤ 10。GORM 的 Count 会复用链上的 Limit 和 Offset，这是高频翻车点。
- 正确做法：用独立会话隔离，例如
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total) - 复杂关联（含
Joins或Preload）时，Count易出错，改用手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN ... WHERE ...) t").Scan(&total) - 别用
Find(&list).RowsAffected取总数——它只返回本次查到的条数（即pageSize）
高偏移或大数据量时，OFFSET 已经不可靠
OFFSET 100000 在 MySQL 上需扫描并丢弃前 10 万行，响应从毫秒级升至秒级，这不是 GORM 能优化的，是 SQL 模型瓶颈。
- 优先考虑游标分页：前端传上一页最后一条的
id，后端查WHERE id > ? ORDER BY id LIMIT 20 - 游标字段必须单调唯一（
id最稳妥，created_at在高并发下可能重复） - 首次请求用
Order("id ASC").Limit(20)，后续用users[len(users)-1].ID作为下一轮lastID - 如果业务允许“不显示总页数”，可查
pageSize + 1条，用是否存在第pageSize + 1条来判断has_next，省掉COUNT
真正上线后出问题的分页，八成栽在三件事上：没校验 page 和 pageSize、忘了 Order、把 Count 和主查询写在同一 DB 链里。尤其是那个被忽略的 Error 字段——Find(&users).Error 不检查，接口就静默返回空切片。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
