gorm不提供逻辑分页api，仅支持limit+offset物理分页；必须显式order排序、校验参数、独立count查询，高偏移应改用游标分页。
GORM 本身不区分物理/逻辑分页，它只提供 Limit 和 Offset —— 用法对了就是物理分页，用错了或绕开了就容易变成逻辑分页。
为什么 GORM 没有“逻辑分页”API？
GORM 的 Find、First 等方法默认只查匹配结果，不会主动拉全表。所谓“逻辑分页”，在 GORM 场景里通常是开发者自己写的错误实践：
- 先执行
db.Find(&all)把全部数据加载进内存，再用all[page*size:(page+1)*size]截取 —— 这是真·逻辑分页，但 GORM 没帮你干这事 - 误以为
RowBounds（MyBatis 概念）在 GORM 里也存在，其实 GORM 根本没有这个类型 - 用
db.Limit(-1).Find(&all)或漏写Limit，导致无意识查全表，后续再切片
换句话说：GORM 不提供逻辑分页能力，也不鼓励你这么做。它把选择权交给你——你要么用 Limit+Offset 做物理分页，要么自己手写全量查询+内存切片（不推荐）。
Limit 和 Offset 怎么用才算是物理分页？
物理分页的核心是：数据库只返回目标页的数据，不传输、不解析无关行。GORM 要达成这点，必须满足三个硬性条件：
-
Offset必须传非负整数，且值 =(page_num - 1) * page_size；传负数或超大数（如Offset(9999999)）可能触发全表扫描或被 DB 拒绝 -
Limit必须显式调用，且值 > 0；传 0 会查全表，传负数在某些驱动下 panic -
Order必须显式指定，例如Order("id ASC")；否则 MySQL/PostgreSQL 不保证结果顺序，同一页刷新可能漏数据或重复
正确示例：
db.Order("id ASC").Offset((p.PageNum - 1) * p.PageSize).Limit(p.PageSize).Find(&users) 错误示例：db.Offset(p.PageNum).Limit(p.PageSize).Find(&users) // Offset 值错，且没 Order
Offset 分页翻到后面越来越慢，是不是“退化成逻辑分页”了？
不是退化，是物理分页的固有缺陷被放大了。MySQL 执行 OFFSET 100000 时，会真实读取并丢弃前 100000 行——不是跳过，是扫描、比较、丢弃。这导致：
- CPU 和 I/O 压力随偏移量线性上升，第 1000 页可能耗时 >1s
- 如果排序字段没索引，性能雪崩更快
- 和逻辑分页无关：它始终只返回 20 条，但从不缓存全量结果
此时该换的是分页策略，不是换“分页类型”。游标分页（WHERE id > ?）才是解法，它不依赖 Offset，避免扫描丢弃，但要求前端传 last_id 而非页码，且排序字段必须有索引。
总数查询 Count 容易踩哪些坑？
Count 看似简单，但在关联查询、条件拼接场景下极易出错：
- 复用带
Limit/Offset的 DB 实例：例如db.Limit(20).Offset(0).Count(&total)，Limit和Offset会被忽略，但开发者常误以为生效 - 漏掉
Joins或Where条件：主查询写了db.Joins("JOIN profiles...").Where("profiles.active", true)，但Count却用db.Model(&User{}).Count()，结果总数不含 JOIN 过滤逻辑 - 用
db.Count()而非db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count()，导致会话污染
最稳妥的做法：总数查询单独构造 DB 实例，显式复现所有过滤条件，不复用链式调用上下文。
真正容易被忽略的点是：GORM 的分页行为完全由 SQL 生成逻辑决定，而 SQL 是否高效，取决于你有没有控制好 Order、Where、索引和参数校验——这些细节一松懈，物理分页就从“省资源”变成“压垮数据库”的起点。
