GORM分页技巧：Limit与Offset使用详解

GORM分页看似简单，实则暗藏多重陷阱：不加ORDER BY会导致结果不可靠、Offset随页码增大而性能断崖式下降、未校验Page/PageSize易引发SQL错误或DoS攻击、忽略Error字段会让接口静默失败——这些细节若不重视，轻则数据错乱、响应缓慢，重则凌晨三点线上告警。掌握正确的分页实践，才是保障高并发下稳定分页的关键。

分页必须显式指定 Order By，否则结果不可靠

GORM 的 Limit 和 Offset 本身不保证顺序，数据库在无 ORDER BY 时返回行序是未定义的——同一查询多次执行可能拿到不同数据，跳页或重复数据就由此而来。

实操建议：

• 所有分页查询前加 Order("id ASC") 或业务主排序字段（如 created_at DESC）
• 避免用 ORDER BY RAND() 分页，性能极差且无法稳定分页
• 如果按非索引字段排序（如 status），注意 MySQL 可能全表扫描，分页深了会变慢

Offset 越大越慢，10 万条后明显卡顿

MySQL 执行 OFFSET 100000 时，仍需扫描前 10 万行再丢弃，CPU 和 I/O 压力陡增。这不是 GORM 的问题，是 SQL 分页的通病。

实操建议：

• 前端限制最大页码（如只允许查前 1000 页），后端校验 page * pageSize
• 真要查深层数据，改用「游标分页」：用上一页最后一条记录的 id 做条件，例如 WHERE id > ? ORDER BY id ASC LIMIT 20
• 不要依赖 Count 查总条数做「共 N 页」展示，高并发下开销大；可改用估算（如 SELECT COUNT(*) FROM table WHERE ... 加缓存）或隐藏总页数

GORM v2 分页写法容易漏掉 Error 检查

很多人直接链式调用 Limit().Offset().Find()，但 Find() 返回的是 *gorm.DB，错误藏在 error 字段里，不显式检查就可能静默失败。

常见错误现象：

• 查不到数据却不报错，result 是空 slice，但 err 非 nil（比如字段名写错、表不存在）
• 用 Scan() 替代 Find() 时更易忽略 err

正确写法示例：

var users []User
err := db.Order("id DESC").Limit(20).Offset((page-1)*20).Find(&users).Error
if err != nil {
    // 处理 err，不是忽略
}

Page 和 PageSize 参数必须校验，别信前端传来的任何值

用户可能传 page=-1、page=999999999、pageSize=0 或非数字字符串，GORM 不做参数清洗，直接拼进 SQL 可能触发语法错误或 DoS。

实操建议：

• 用 strconv.Atoi 转换并判断错误，拒绝非法数字
• page 至少为 1，pageSize 限定范围（如 1–100）
• 对超大 pageSize（如 > 1000）直接返回错误，不交给数据库执行
• 如果用 Gin 等框架，可在中间件统一校验，避免每个 handler 重复写

分页看着简单，真正上线后出问题的，八成卡在排序缺失、Offset 性能崩塌、或者参数没校验——尤其是那个被忽略的 Error 字段，它不会喊你，但会在凌晨三点默默让接口返回空数组。

本篇关于《GORM分页技巧：Limit与Offset使用详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！