GORM框架结合Gin框架实现快速Web分页接口-Golang-PHP中文网

用Limit+Offset分页需配合Count总数查询、参数校验和边界保护，否则Offset过大导致MySQL全表扫描、CPU飙升、超时；应限制Page≤1000、Size≤100，并用validator校验输入。

gorm框架结合gin框架实现快速web分页接口

直接说结论：用 Limit + Offset 是最稳妥的起步方式，但必须配合 Count 查询总数，且不能跳过参数校验和边界保护。

为什么不能只写 `Limit` 和 `Offset` 就完事？

很多人照着示例一写就跑，结果线上出问题：页面卡死、MySQL CPU 暴涨、翻到第 100 页直接超时。根本原因是没意识到两个事实：

Offset 越大，数据库越要扫描前面所有行——OFFSET 100000 不是跳过 10 万条记录，而是让 MySQL 先读、再丢弃 10 万条
Count(*) 在无索引或大数据量下也会变慢，尤其带 WHERE 条件时

所以实际分页不是“拼 SQL”，而是“控制查询成本”。建议默认加限制：Page ≤ 1000，Size ≤ 100，并在日志里埋点记录高偏移请求。

`ShouldBindQuery` 绑定分页参数时容易漏掉什么？

用 Gin 的 ShouldBindQuery 接收 page 和 size 很方便，但几个关键点常被忽略：

没设默认值：前端不传 page 时结构体字段为 0，Offset(-1 * size) 会 panic
没做范围检查：size 传个 10000，一次查上万条数据，内存和网络都吃不消
没处理负数或非数字：比如 ?page=abc，ShouldBindQuery 默认静默失败（字段保持零值），而不是报错

推荐写法：

type PageQuery struct {
    Page  int `form:"page" binding:"required,min=1,max=1000"`
    Size  int `form:"size" binding:"required,min=1,max=100"`
    Keyword string `form:"keyword"`
}

然后用 c.ShouldBindQuery(&q)，靠 validator 自动拦截非法输入。

GORM框架 1.30.3

GORM框架 1.30.3版本源码包下载，版本号 1.30.3，适合在 1.30 主线早期节点做源码留档、依赖回放和升级前后行为对照。

下载

总数统计 `Count` 怎么写才不出错？

总数必须和实际数据查询用**完全一致的 WHERE 条件**，否则前后端分页错位。常见错误是：

在 Count 时漏了软删除字段（如 deleted_at IS NULL）
对 Keyword 做了 LIKE 模糊匹配，但 Count 没加，导致总数不准
用 db.Model(&User{}).Where(...).Count(&total)，但 Model 指向了空结构体，GORM 可能忽略表名或别名

安全写法是复用同一个 *gorm.DB 实例：

db := config.DB.Where("deleted_at IS NULL")
if q.Keyword != "" {
    db = db.Where("name LIKE ?", "%"+q.Keyword+"%")
}
var total int64
db.Count(&total).Error // 注意：Count 返回的是 int64
<p>var users []User
db.Limit(q.Size).Offset((q.Page - 1) * q.Size).Find(&users)</p>