Count不准主因是复用同一*gorm.DB实例导致Limit/Offset污染，正确做法是db.Session(&gorm.Session{NewDB: true}).Model(&T{}).Where().Count()或手写子查询；关联分页须两阶段查或窗口函数；高并发下必须用游标分页。
GORM 没有安全可靠的“通用分页”模式，复杂业务下必须按场景拆解——不是选错方案，而是混用方案会出事。
Count 查询总条数为什么总是不准
最常见原因是复用了同一个 *gorm.DB 实例：比如 db.Where("status = ?", "active").Limit(20).Offset(40).Count(&total)，这个 Count 会继承前面的 Limit 和 Offset，结果永远 ≤ 20。
- 正确做法是新建干净上下文：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total) - 关联查询（如带
Joins或Preload）时，Count极易漏条件或误统计，直接手写子查询更稳：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE u.status = ?) t", "active").Scan(&total) - 如果业务允许不返回总页数（比如无限滚动），可查
pageSize + 1条，只判断是否有下一页：db.Limit(pageSize + 1).Find(&items)，省掉Count开销
Preload 关联分页为什么不能直接用
写 db.Preload("Orders").Limit(10).Find(&users) 看似合理，实际会触发 N+1 式加载：先查 10 个用户，再为每个用户发一条 SELECT * FROM orders WHERE user_id = ?，最终可能拉回几百条订单，且无法控制“每个用户只取最新 3 个”。
- 正确做法是两阶段查：先分页查主表 ID 列表（
db.Select("id").Limit(10).Find(&userIDs)），再用IN批量查关联数据（db.Where("user_id IN ?", userIDs).Order("created_at DESC").Limit(30).Find(&orders)） - 若需严格分页关联（如“每个用户最新 3 个订单”），得用窗口函数（MySQL 8.0+/PostgreSQL），GORM 不支持原生生成，需
db.Raw手写 -
Preload的Limit参数（如Preload("Orders", db.Limit(3))）在 GORM v2.2+ 后已废弃，部分版本静默忽略，别依赖
什么时候必须放弃 Offset 分页
OFFSET 不是逻辑页码，是物理行偏移。当表每秒有写入、删除，或页码 > 50 时，同一条记录可能在第 49 页和第 51 页重复出现，或直接消失——这不是 bug，是 MySQL/PostgreSQL 的行为本质。
- 高并发写入场景（如订单、日志、消息流）：必须切游标分页，前端传上一页最后一条的
id和created_at，后端查WHERE created_at - 索引必须覆盖排序字段：单独
created_at索引不够，要建联合索引INDEX idx_created_id (created_at, id)，否则回表严重 - 游标分页无法跳转任意页（比如直接点“第 100 页”），这是设计取舍，不是缺陷；真有跳页需求，说明业务没想清数据实时性边界
第三方 Paginate 插件到底能不能用
插件如 github.com/joshbetz/pagination 提供了 Paginate 方法，但它是语法糖，不是解决方案——它不解决排序缺失、Count 复用、Preload 错误等核心问题，反而容易掩盖校验漏洞。
- 插件内部仍是调
Limit/Offset，page=0或pageSize=0可能导致 panic 或全表扫描（SQLite 下Limit(0)行为异常） - GORM 小版本升级常破坏插件兼容性（如 v2.6+ 修改
Scope语义后，老插件漏数据），升级前必须跑完整分页回归 - 如果你需要快速验证逻辑，插件可临时用；但上线前，必须手动补全
Order、隔离Count、禁用Preload，否则等于没改
真正难的不是写对一行 Offset，而是判断当前接口该用游标还是传统分页、该查总数还是只判下一页、该预加载还是分两步——这些决策藏在业务语义里，不在 ORM 文档中。
