分页必须手写limit+offset，禁用第三方paginate；强制校验page≥1、pagesize≤100；必须显式order避免数据漂移；总数查询需独立db实例；高偏移量须切游标分页。
分页必须手写 Limit + Offset，GORM 没有 Paginate
GORM 从 v1 到 v2.6+ 都不提供原生 Paginate 方法——所有“自动分页”封装要么是第三方库（如 github.com/joshbetz/pagination），要么是你自己写的函数。在自动化运维监控平台这类对稳定性要求极高的场景里，依赖插件反而增加风险：版本错配、Scope 行为变更导致漏数据、参数校验被掩盖。直接用 Limit 和 Offset 最可控，也最容易定位慢查询或越界 panic。
-
Offset((page - 1) * pageSize)必须写在Limit(pageSize)前面（虽 v2 中顺序可互换，但固定写法避免跨版本歧义） -
page小于等于 0 时强制设为 1；pageSize超过 100 就截断，防止告警表百万级数据下OFFSET 100000直接拖垮 MySQL - 别信“前端传啥我就用啥”，
c.ShouldBindQuery(&p)绑定结构体后，仍要手动校验p.PageSize > 0——Limit(0)在 SQLite 下会返回全表，在 PostgreSQL 下可能报错
告警分页必须显式 Order，否则数据会漂移
运维监控平台的告警事件是高频写入场景（每秒可能插入数十条），没加 Order 的分页查询结果不可重现：同一页刷新两次，可能漏掉刚插入的高优告警，或重复显示已处理的旧告警。这不是 GORM 的 bug，是 SQL 标准行为——无序查询不保证行序稳定。
- 首选
Order("id DESC")（假设id是自增主键且有索引），次选Order("created_at DESC, id DESC")，避免仅用created_at导致时间相同时排序随机 - 如果告警表按
status或level分区，确保ORDER BY字段和查询条件字段一起建联合索引，例如(status, created_at, id) - 别为了“省一个字段”去掉
Order，线上环境出现告警丢失比多写 10ms 响应更致命
总数查询必须隔离 DB 实例，不能复用链式调用
前端告警列表页需要总条数渲染页码控件，但 db.Where("status = ?", "unhandled").Count(&total) 如果写在同一个 *gorm.DB 链上，会继承前面的 Limit 和 Offset，导致 total 永远 ≤ 每页数量。
- 安全做法是新建独立实例：
db.Session(&gorm.Session{NewDB: true}).Model(&Alert{}).Where(...).Count(&total) - 如果查询含
Joins或复杂子查询，Count容易不准，改用手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM alerts WHERE ...) t").Scan(&total) - 注意：两次查询（Count + Find）之间若有新告警写入，总数和当前页数据天然不一致——这是业务可接受的最终一致性，不必强求事务锁表
高偏移量或实时滚动场景必须切游标分页
当运维平台告警积压到几十万条，用户翻到第 500 页（OFFSET 49900）时，MySQL 实际要扫描并丢弃前 49900 行，响应时间从 20ms 拉到 2s+。这时传统分页已失效，必须切换游标分页。
- 前端首次请求传空
cursor，后端查ORDER BY created_at DESC, id DESC LIMIT 20；后续请求带cursor=2024-08-20T10:30:00Z_12345（时间戳+ID 拼接），SQL 改成WHERE created_at - 游标值必须来自当前页最后一条记录的确定性字段，不能用
updated_at（可能为空或被批量更新） - 游标分页无法跳页（比如直接翻到第 100 页），但运维场景中“无限滚动加载更多”比“跳转指定页码”更常用，且性能稳定
游标分页的排序字段索引、参数校验的硬边界、Count 查询的实例隔离——这三点在告警这种低延迟、高可靠要求的场景里，任何一个被忽略都会导致线上问题。不是“能跑就行”，而是“必须稳”。
