GORM无内置分页方法，必须手动组合Limit+Offset，并严格完成参数校验（page≤0设为1、pageSize硬限1–100）、强制显式Order排序（如Order("id DESC")）、总数查询隔离（避免复用同一db实例）。
GORM 没有内置分页方法，所谓“配置中心版本历史分页”必须手动组合 Limit + Offset，且不能跳过参数校验、排序强制、总数隔离这三个关键动作。
分页参数解析和安全截断必须在 GORM 调用前完成
配置中心的版本历史接口（如 /configs/{key}/versions?page=3&page_size=50）常被恶意刷或前端误传，page 为 0、负数、超大值，page_size 为 0 或 10000，都会直接透传给 Offset/Limit 导致 panic 或 DB 拒绝服务。
-
page小于等于 0 时，统一设为 1；不要返回错误——用户点错“第 0 页”不是要报 400 -
page_size必须硬限制，例如上限设为 100：用min(p.PageSize, 100)截断，而不是拒掉请求 - 空字符串、非数字（如
page=abc）需提前拦截：c.ShouldBindQuery(&p)失败就直接c.JSON(400, ...)，别 fallback 到默认值 - 别用
strconv.Atoi(c.Query("page"))直接转，没判空会 panic
ORDER BY 是分页稳定的前提，不是可选项
配置版本历史表通常有 id、version、created_at 字段，但若查询不加 Order，MySQL/PostgreSQL 不保证两次 OFFSET 查询结果一致——尤其在后台频繁发布新版本时，同一页可能漏掉某次变更或重复出现旧版本。
- 必须显式写
Order("id DESC")或Order("created_at DESC, id DESC")；只用created_at DESC不行，时间重复时顺序不可控 - 排序字段必须有索引，否则
OFFSET扫描成本随数据量线性上升；id主键天然有索引，最稳 - 别写
Order("RAND()")做“随机版本查看”，这会彻底破坏分页语义且无法翻页
Count 查询必须与分页查询完全隔离
前端分页控件需要总条数渲染页码，但很多人写成 db.Where(...).Limit(n).Offset(m).Count(&total)，结果 total 永远 ≤ n——因为 Count 继承了前面链上的 Limit 和 Offset，这是 GORM 最高频误用点。
- 简单场景：用
db.Session(&gorm.Session{NewDB: true}).Model(&ConfigVersion{}).Where(...).Count(&total)，靠NewDB: true隔离上下文 - 复杂查询（含
Joins或多表关联）：手写子查询更可靠，例如db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM config_versions WHERE key = ?) AS t", key).Scan(&total) - 如果业务允许（比如只显示“下一页”按钮），可省掉
COUNT：查page_size + 1条，有第page_size + 1条就说明还有下一页
当版本数量超 10 万，必须切游标分页
配置中心某些 key 的历史版本可能达百万级（如高频灰度开关），此时 OFFSET 999999 在 MySQL 中要真实扫描并丢弃前 99 万行，响应从毫秒变秒级，优化不在 Go 层，而在查询模型。
- 游标分页依赖确定性排序，首选
id DESC：首次请求ORDER BY id DESC LIMIT 20，后续请求带last_id=12345，SQL 改为WHERE id < 12345 ORDER BY id DESC LIMIT 20 - 避免用
created_at单字段做游标，时间精度低或批量插入易重复；必须用created_at DESC, id DESC组合，并建联合索引 - 游标分页不能混用
Preload，关联数据（如发布人信息）应分两步：先查出本页所有version.id列表，再用IN批量加载
真正难的不是写 Offset 和 Limit，而是意识到：分页不是“取第几页”，而是“在确定顺序下取一段快照”。任何跳过校验、忽略排序、复用 Count 的做法，上线后都会在凌晨三点报警。
