gorm无paginate方法，分页需手动处理limit/offset、排序、参数校验和总数查询；page或pagesize非法会导致panic、全表返回或性能问题；必须显式order确保结果稳定；count需独立查询；大数据量应改用游标分页。
GORM 没有 Paginate 方法，所谓“开箱即用分页”全是错觉。你必须手写 Limit 和 Offset，并同步处理排序、参数校验、总数查询——漏掉任一环，上线后就可能丢数据、查得慢、被刷垮。
为什么不能直接用 Offset((page - 1) * pageSize)
这不是数学错误，而是运行时风险点。GORM 不做任何输入清洗，page=0 会传 Offset(-1) 导致 panic；page=abc 用 strconv.Atoi 解析失败却没判错，结果 Offset(0) 返回全表（SQLite 下尤其危险）；pageSize=10000 可能触发 MySQL 的 max_allowed_packet 拒绝或拖慢整个连接池。
- 前端参数必须用结构体 +
ShouldBindQuery绑定，而非裸调c.Query() -
PageNum小于 1 时强制设为 1，不返回错误（用户点错页码不是 bug，是交互常态） -
PageSize必须硬限制，比如limit := min(p.PageSize, 100)，超限就截断，别拒请求 - 别信“默认值兜底”——
int字段未传就是 0，0是非法Offset值
为什么分页必须显式写 Order
没 Order 的 Limit/Offset 查询，结果不可预测。MySQL 和 PostgreSQL 都不保证无序查询的行顺序，哪怕表静态、没写入，两次执行也可能返回不同记录。典型现象：翻页时某条记录消失，或同一记录在两页里重复出现。
- 必须用确定性排序，例如
Order("id ASC")或Order("created_at DESC, id DESC") - 禁止单用
Order("status ASC")——status 值重复率高，数据库内部排序不稳定 - 慎用
Order("created_at DESC")：毫秒级并发写入下时间可能重复，补上id DESC才可靠 -
Order("RAND()")完全不能用于分页，无法支持“下一页”，且全表扫描极慢
为什么 Count 不能和分页共用一个 *gorm.DB 实例
db.Where("x = ?", v).Limit(10).Offset(20).Count(&total) 查出来的 total 永远 ≤ 10。GORM v2 中 Count 会复用链式调用里已有的 Limit/Offset，这不是 bug，是设计如此。
- 正确做法是拆成两个独立查询：先构建带条件的
query := db.Where("x = ?", v)，再分别调query.Count(&total)和query.Offset().Limit().Find(&list) - 复杂 JOIN 场景下，
Count可能比主查询还慢，可考虑手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE ...) AS t").Scan(&total) - 如果业务允许（如后台列表不要求精确总页数），可只查
pageSize + 1条，用len(results) > pageSize判断是否有下一页，省掉COUNT
什么时候必须放弃 Offset 改用游标分页
当单表行数超 10 万，Offset(50000) 在 MySQL 上实际要扫描并丢弃前 5 万行，响应从 20ms 拉到 1.5s+。这不是 GORM 能优化的，是 SQL 层面的物理限制。
- 游标分页核心是 WHERE + 排序字段：例如上一页最后一条是
id=1005，下一页就查WHERE id > 1005 ORDER BY id LIMIT 20 - 排序字段必须有索引，否则性能更差；推荐用主键
id或组合索引(created_at, id) - GORM 不提供原生游标封装，需手动拼条件，但逻辑清晰可控：
db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&list) - 注意游标分页无法跳转任意页，但对无限滚动、消息流等场景更合适，且天然规避了 OFFSET 的性能悬崖
最易被忽略的其实是排序字段的索引覆盖——没索引的 Order 让 Offset 更慢，让游标分页失效。上线前务必用 EXPLAIN 看执行计划，别只盯着 Go 代码。
