gorm分页必须拆开查总数与列表、显式排序、隔离会话；count复用limit/offset导致总数≤每页条数，正确做法是db.session(newdb:true).model().where().count()或手写子查询。
直接用 Limit + Offset 能跑，但总数不准、性能差、数据可能重复或丢失——这不是配置问题，是 SQL 语义和 GORM 链式调用机制共同导致的硬伤。必须拆开查、显式排序、隔离会话。
Count 总数为什么总是错？
常见写法 db.Where("status = ?", "active").Limit(20).Offset(40).Count(&total) 返回的 total 永远 ≤ 20，因为 Count() 会复用前面链上的 Limit 和 Offset，实际执行的是 SELECT COUNT(*) ... LIMIT 20 OFFSET 40，统计的是“第 3 页的数据条数”，不是总匹配数。
- 总数查询必须独立构造：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total)，NewDB: true确保不继承原链的 Limit/Offset - 带 JOIN 的复杂查询，
Count()更容易漏条件——比如你写了Joins("JOIN profiles ON users.id = profiles.user_id")查数据，但Count()没加这个 JOIN，总数就虚高；此时应手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE p.active = ?) AS t", true).Scan(&total) - 如果业务允许（如 Feed 流），干脆别返回
Total，改用has_next：查limit + 1条，有第limit + 1条就设has_next = true，省掉 COUNT 开销
Limit 和 Offset 顺序与校验陷阱
Offset() 必须在 Limit() 前调用，虽然 GORM v2 允许互换，但语义混乱易出错。更关键的是参数未经校验时，page=0 会导致 Offset(-10) panic，page_size=10000 可能拖垮数据库。
- 用结构体绑定 + validator 标签强制约束：
type PaginationRequest struct { Page int `form:"page" binding:"gte=1"` Limit int `form:"limit" binding:"gte=1,lte=100"` } - 计算 offset 时别裸写
(p.Page - 1) * p.Limit，先做截断：offset := (p.Page - 1) * p.Limit，但若p.Page极大（如 100000），offset 会溢出 int，建议转成int64并加上限检查 - 不要把前端传的
page直接当页码用——高并发写入下，“第 50 页”这个概念本身就不稳定；真正安全的是游标分页
游标分页怎么写才不丢数据
游标分页不是“优化选项”，而是数据频繁变更场景下的生存必需。核心是用上一页最后一条记录的排序字段值（如 id）作为下一页起点，绕过 OFFSET 的物理扫描缺陷。
- 排序字段必须单调、有索引：
id最稳；若用created_at，必须加id作二级排序（Order("created_at DESC, id DESC")），否则高并发下时间戳重复会导致漏数据 - 首次请求不带游标：
db.Order("id ASC").Limit(20).Find(&users)；后续请求必须传last_id（不是页码！），然后db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 前端必须透传
last_id，后端不做转换——任何“把 last_id 转成 page”的中间层都会 reintroduce OFFSET 缺陷 - 如果用户篡改
last_id（如传负数、非数字），Where("id > ?", lastID)会查空，应提前校验并返回400 Bad Request，而不是静默 fallback 到第一页
Preload 关联分页为什么不能直接用
在分页查询里写 Preload("Orders") 看似方便，实则危险：GORM 先查出 20 个用户，再为这 20 个用户分别发 SELECT * FROM orders WHERE user_id IN (?)，结果可能加载几千条订单，且无法控制“每个用户只取最新 3 条”。
- 正确做法是分两步：先分页查主表（
users），拿到[]user.ID后，再用IN批量查关联表，并手动按user_id分组、取前 N 条 - 或者改用子查询 JOIN（需数据库支持），例如：
db.Joins("JOIN (SELECT * FROM orders o2 WHERE o2.id IN (SELECT id FROM orders o1 WHERE o1.user_id = users.id ORDER BY created_at DESC LIMIT 3)) AS latest_orders ON latest_orders.user_id = users.id") - 更轻量的方案是前端分两次请求：先拉用户列表，再根据选中的用户 ID 单独查其订单
真实项目里最容易被忽略的，是排序字段没建索引、总数查询复用 DB 实例、以及把游标当成页码二次转换——这三个点一错，分页就从功能缺陷变成线上事故。
