不查count分页可行，因总数是业务需求而非技术强制；常被误用在于无脑添加导致全表扫描、条件复用出错、高并发下数据失真，且游标分页更适配“加载更多”场景。
不查 COUNT 就分页，为什么可行又常被误用
GORM 分页本身不要求必须统计总数——Count 是业务需要，不是技术强制。但很多人一写分页就无脑加 Count，结果在大表上拖慢接口、压垮数据库，甚至因 WHERE 条件复用导致总数错得离谱。
真正需要“总页数”或“第 X 页/共 Y 页”展示时才查总数；如果只做“下一页”“加载更多”，或前端用无限滚动，总数就是冗余开销。
- 总数查询会触发全表扫描（尤其没 WHERE 或索引覆盖差时）
-
db.Where(...).Count()和db.Where(...).Limit().Offset()共用一个*gorm.DB实例时，Count可能意外继承前面的Limit或Offset，返回错误值 - 高并发场景下，总数和列表数据之间存在时间差，所谓“共 1024 条”可能刚查完就变成 1025 条，数字本身已失真
手写 Limit + Offset 分页，跳过 Count 的标准写法
去掉 Count 后，核心只剩两步：校验参数、拼 LIMIT/OFFSET。GORM v2 里顺序可互换，但为兼容性和可读性，仍建议固定用 Offset().Limit()。
-
page必须 ≥ 1，否则Offset((page-1)*pageSize)可能为负，触发 panic -
pageSize必须 > 0，且应设硬上限（如 100），避免Limit(10000)直接拖垮 MySQL -
Order必须显式声明，否则无序分页结果不可重现（同一页刷新可能漏/重） - 别把
db.Where(...).Count(&total)和db.Where(...).Offset().Limit().Find()写在同一个链式调用里
示例：
var users []User
page, pageSize := 3, 20
if page 100 {
pageSize = 20
}
offset := (page - 1) * pageSize
<p>err := db.Model(&User{}).
Where("status = ?", "active").
Order("id ASC").
Offset(offset).
Limit(pageSize).
Find(&users).Error
</p>
用 Scopes 或 Clauses 封装无总数分页逻辑
如果你反复写 Offset().Limit().Order()，可以抽成可复用的 Scope，它不碰 Count，只管切数据。
Scopes 更轻量，适合项目初期快速统一风格：
func PaginateNoCount(page, pageSize int) func(db *gorm.DB) *gorm.DB {
return func(db *gorm.DB) *gorm.DB {
if page 100 {
pageSize = 20
}
offset := (page - 1) * pageSize
return db.Offset(offset).Limit(pageSize)
}
}
<p>// 使用
db.Scopes(PaginateNoCount(p.PageNum, p.PageSize)).Order("created_at DESC").Find(&users)
</p>
注意：Scope 本身不执行 SQL，只是修饰 *gorm.DB，所以不会自动加 Count——这点恰恰是它适合“无总数分页”的根本原因。
游标分页天然不依赖总数，但要改前端传参方式
如果业务允许放弃“页码”概念，游标分页（cursor-based）是最干净的无总数方案。它不计算总条数，也不跳过 N 条，而是靠排序字段值推进查询。
- 首次请求：
db.Order("id ASC").Limit(20).Find(&users) - 后续请求传
last_id=12345：db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 必须确保
ORDER BY字段有索引（如id主键自带），否则性能崩塌 - 前端不再传
page，改传cursor（如 base64 编码的id或created_at时间戳） - 无法跳转到任意页（比如“去第 50 页”），但对“加载更多”场景更稳定、更快
最容易被忽略的一点：游标分页下，Preload 关联查询不能直接跟主查询一起做，得拆成两步——先查主表 ID 列表，再用 IN 批量查关联数据。
