GORM的Limit和Offset由dialector翻译为各数据库适配SQL，非统一拼接；Count默认跳过Limit/Offset但需避免链式调用污染，Offset性能问题源于数据库引擎扫描丢弃行的物理机制。
分页SQL生成由dialector决定，不是GORM统一拼的
GORM 的 Limit 和 Offset 不是自己拼SQL字符串，而是交给具体数据库驱动（dialector）翻译。MySQL 驱动输出 LIMIT 10 OFFSET 20，PostgreSQL 驱动也一样；但 SQLite 会转成 LIMIT 10 OFFSET 20，SQL Server 则变成 OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY。你不能假设所有数据库行为一致——比如在 SQL Server 上漏写 ORDER BY 会直接报错，而 MySQL 只是不保证顺序。
常见错误现象：db.Limit(10).Offset(100).Find(&users) 在 PostgreSQL 上跑得通，在 SQL Server 上 panic 报 “The ORDER BY clause is required...”；这不是 GORM bug，是底层 dialector 按标准 SQL 要求校验的。
- 别在跨数据库项目里硬编码 LIMIT/OFFSET 逻辑，改用
Scopes封装可移植分页函数 - 若自定义 dialector（如对接达梦 DM），必须实现
BuildCondition和Explain方法，否则Limit会被忽略或静默失效 - 查看实际发出的 SQL：启用
logger.Info级别日志，注意看日志里是LIMIT ? OFFSET ?还是FETCH NEXT ? ROWS
Count查询复用Where条件但不复用Limit/Offset，这是设计不是bug
GORM v2 的 Count 方法默认只复用 Where、Joins、Scopes 等前置条件，但明确跳过 Limit 和 Offset。所以 db.Where("status = ?", "active").Limit(10).Count(&total) 查出的 total 是全量匹配数，不是 10。
但这个“跳过”发生在构建 SQL AST 阶段，不是运行时判断。如果你链式调用顺序错乱，比如先 Count 再 Limit，那 Count 就真会带上 Limit —— 因为它拿到的是当前链状态。
- 正确写法：用变量暂存条件构建器，例如
query := db.Where("status = ?", status)，再分别调query.Count()和query.Limit().Offset().Find() - 错误写法：
db.Where(...).Count().Limit().Find()，第二个链式调用会污染第一个 - 某些旧版驱动（如早期达梦 dmgorm1）没实现 Count 的条件剥离逻辑，会导致 count 结果恒为 0 或 panic，必须升级到 dmgorm2
Offset性能崩塌不是GORM问题，是数据库引擎特性
Offset 在 GORM 层只是个参数透传，真正执行慢是因为 MySQL/PostgreSQL 扫描并丢弃前 N 行。GORM 不可能自动把 Offset(50000) 优化成游标分页——它不知道你的主键是否连续、排序字段是否有索引、业务能否接受“跳过中间页”。
当 Offset 值超过 10000，响应延迟就明显上升；超过 50000，MySQL 通常要 1s+。这不是配置能调优的，是 B+ 树遍历的物理代价。
- 游标分页必须手动实现：前端传上一页最后一条记录的
id和created_at，后端构造WHERE id > ? AND created_at 条件 - 别依赖
RowsAffected当总数——它返回的是本次查询命中的行数，不是全表满足条件的总数 - 如果必须用 Offset（比如管理后台导出全量），至少加
FORCE INDEX提示，但需确认该索引覆盖了 Where + Order 字段
分页参数校验必须在GORM之外做，它不拦非法输入
GORM 对 Limit 和 Offset 参数不做任何类型检查或范围限制。传 Limit(-1) 可能生成 LIMIT -1，MySQL 直接报错；传 Offset("abc") 会 panic：cannot convert string to int。
这些都不是中间件或 Gin ShouldBindQuery 能兜住的——ShouldBindQuery 失败时返回 error，但很多人写成 if err != nil { /* 忽略 */ }，导致后续 Offset 接收零值或随机值。
- 必须显式校验：
page, _ := strconv.Atoi(c.Query("page"))前先if c.Query("page") == ""，避免 atoi 返回 0 -
Offset((page-1)*size)要防整数溢出：当 page=1000000、size=1000 时，结果超 int64，MySQL 报错 ER_PARSE_ERROR - pageSize 建议硬限制在 1–100，超出直接
c.AbortWithStatusJSON(400, ...)，别用min(size, 100)默默降级——前端翻页控件会显示异常
分页的底层适配点藏在 dialector 实现里，而不是 GORM 的 API 表面；一旦切库或换驱动，连 SQL 语法都可能变。最容易被忽略的是：Count 和 Find 共享 Where 条件的前提，是你没在中间插入任何改变链状态的操作——比如一个自定义 Scope 里偷偷调了 Limit，就会让 Count 结果失真。
