一个能被前端稳定消费的分页响应体至少需包含data、total、page、limit四个字段：data必须为指针类型（如*[]user）以供gorm写入，total为int64防溢出，page和limit用int便于shouldbindquery安全绑定。
分页响应体必须包含哪些字段
一个能被前端稳定消费的分页响应体，至少要带 Data、Total、Page、Limit 四个字段。缺 Total 就没法算总页数；缺 Page 和 Limit，前端无法构造下一页 URL；Data 类型必须是 []interface{} 或具体切片类型指针（如 *[]User），否则 GORM 查询结果无法安全赋值。
常见错误现象：Total 字段始终为 0，或 Data 返回空数组但日志显示查到了数据——大概率是 Data 字段没用指针类型，GORM 的 Find() 写不进非指针变量。
-
Total必须是int64，避免 MySQLCOUNT(*)超过int上限时溢出 -
Page和Limit建议用int（非指针），因为它们是输入参数，绑定时 Gin 的ShouldBindQuery对非指针整型能正确处理零值校验 -
Data字段必须声明为指针类型，例如Data *[]User，否则 GORM 不会写入内容
GORM 分页中 Count() 和 Find() 条件不一致怎么破
这是微服务里最常踩的坑：同一个 *gorm.DB 实例先调 Count() 再调 Find()，结果 Total 对不上，或者 Find() panic。
根本原因是 GORM v2 的链式调用会修改实例内部状态。比如你在 Where() 后接 Count()，它可能悄悄加了 GROUP BY 或删了 ORDER BY，后续 Find() 就沿用了这个“脏”状态。
- 正确做法：用
db.Session(&gorm.Session{NewDB: true})新建干净实例做Count() - 更稳妥写法：显式用
db.Model(&User{}).Where(...).Count(&total)，不依赖当前 db 链路 - 如果用了多个 Scopes（如
StatusScope+TimeRangeScope），分页 Scope 必须放在最后，否则Offset/Limit可能被前面 Scope 的Group或Having干扰
Page 结构体里 Current 和 Size 为什么必须用指针
不是为了“看起来高级”，而是为了在 Scope 内做默认值填充和边界截断时，能真正改到原始变量。
Gin 的 ShouldBindQuery 对非指针字段绑定失败时，会静默设为零值（0）。而 page=0 会导致 Offset(-size)，GORM 直接 panic；size=0 会让 Limit(0) 失效，变成全表扫描。
-
Current *int：允许你在 Scope 里判断if p.Current == nil || *p.Current -
Size *int：同理，if p.Size == nil || *p.Size 100 { *p.Size = 20 } -
Total *int64：必须是指针，因为它是输出字段，Scope 要往里写值；且不能和Current/Size放在同一个结构体里直接绑定 query，否则前端传?page=1&size=20会把Total也当输入解析
Order 必须显式声明，别信“数据库默认有序”
GORM 不保证无序查询的行顺序稳定。主从延迟、MVCC 版本、并发写入都可能导致同一条 OFFSET/LIMIT 查询两次返回不同记录——漏数据或重复，这不是 bug，是数据库行为。
错误写法：db.Scopes(Page(p)).Find(&users)（没 Order）
正确写法：db.Order("id ASC").Scopes(Page(p)).Find(&users)，且 id 字段必须有索引。
- 业务要求按时间排序？用
created_at DESC，但确保该字段有索引，否则分页性能断崖下跌 - 复合排序（如
status ASC, created_at DESC）更安全，能避免因主键重复导致的分页偏移错乱 - 游标分页（cursor-based）在大数据量场景下比 offset 分页更可靠，但需要客户端传上一页最后一条的
id或created_at
分页不是加两个参数就完事。最危险的点往往藏在 Count() 和 Find() 共享 db 实例、Order 缺失、以及 Page 结构体字段类型误用这三处——它们不会报错，但会在高并发或大数据量时突然崩掉。
