<p>GORM分页通过Limit和Offset生成SQL，如SELECT * FROM users ORDER BY id ASC LIMIT 20 OFFSET 40；必须显式Order保证顺序稳定，Count需独立执行且避免复用带Limit/Offset的DB实例。</p>
分页SQL在GORM中怎么生成的
GORM 的 Limit 和 Offset 不是魔法，它们只是往 SQL 语句末尾拼上 LIMIT ? OFFSET ?。你调用 db.Limit(20).Offset(40).Find(&users)，最终生成的就是类似 SELECT * FROM users ORDER BY id ASC LIMIT 20 OFFSET 40 的语句——前提是显式写了 Order。
关键点在于：GORM v2 的链式调用是“惰性组装”，所有中间方法（Where、Order、Limit）都只往 Statement 结构体里塞参数，直到遇到 Find 这类结尾方法才真正拼 SQL 并执行。所以顺序写成 Offset().Limit() 或 Limit().Offset() 在 v2 中都能生效，但前者更符合直觉，也避免在旧版或某些封装里踩坑。
为什么没写 Order 会导致分页错乱
数据库不保证无序查询的行序稳定。哪怕表数据没变，两次 SELECT * FROM users LIMIT 10 OFFSET 0 也可能返回不同顺序的 10 条记录——MySQL 的 InnoDB 在无索引/无排序时按聚簇索引物理顺序读，但这个顺序受插入、删除、页分裂影响，不可依赖。
分页依赖“位置感”：第 2 页必须紧接第 1 页之后。一旦排序不固定，OFFSET 10 可能跳过某条本该在第 1 页末尾的记录，或者重复出现它。
- 必须显式调用
Order("id ASC")或Order("created_at DESC") - 排序字段最好有索引，否则
ORDER BY本身就会变慢，拖累整个分页 - 复合排序如
Order("status ASC, id DESC")也可以，但要确保所有分页查询用完全相同的排序表达式
Count(*) 查询是怎么被触发的
前端分页控件需要总条数来渲染页码，所以几乎每次都要查一次 COUNT(*)。但 GORM 不会自动帮你做这件事——你得自己写：
var total int64 db.Model(&User{}).Where("status = ?", "active").Count(&total).Error
注意三点：
- 别复用主查询的
*gorm.DB实例去查总数，比如db.Where(...).Limit(...).Offset(...).Count(&total)——Limit和Offset会被带进 COUNT 语句，变成SELECT COUNT(*) LIMIT 20 OFFSET 40，结果永远是 0 或 20，不是真实总数 - 用
Model(&User{})显式指定表，避免结构体指针为 nil 时出错 - WHERE 条件必须和主查询完全一致，否则总数和列表对不上；建议把条件提取成可复用的函数或 scope
Offset 越大越慢的根本原因
MySQL 执行 LIMIT 20 OFFSET 10000 时，并不会直接跳到第 10001 行。它得先扫描前 10020 行，过滤、排序（如果有），再丢弃前 10000 行，只返回后 20 行。数据量越大，OFFSET 越高，扫描成本线性上升，甚至引发磁盘临时表或 filesort。
这不是 GORM 的锅，是 SQL 标准行为。所以当页码超过 50 或记录超 10 万，就得换思路：
- 前端限制最大可翻页数（比如只允许 page ≤ 100）
- 改用游标分页：记住上一页最后一条的
id，下一页查WHERE id > ? ORDER BY id ASC LIMIT 20 - 用覆盖索引优化 COUNT，例如
SELECT COUNT(id) FROM users WHERE status = ?，比COUNT(*)快得多
游标分页不能跳页，但加载无限滚动或“下一页”场景足够稳；而传统分页的 OFFSET 天然不适合深分页——这点容易被忽略，直到线上慢查询告警炸出来。
