gorm的limit+offset分页在高并发下会雪崩，因数据库执行offset需真实扫描并丢弃前n行，i/o和cpu开销线性上涨，导致连接池占满、cpu拉满、超时频发；同一页刷新可能返回不一致结果，必须加确定排序、校验参数、避免复用db实例查总数。
为什么 GORM 的 Limit + Offset 在高并发下会雪崩
因为数据库（MySQL/PostgreSQL）执行 OFFSET 100000 时，必须真实扫描并丢弃前 10 万行——不是跳过，是逐行读、排序（若没走对索引）、比较、丢弃。每翻一页，I/O 和 CPU 开销线性上涨。5000 页 ≈ 扫 100 万行，连接池迅速占满，CPU 拉满，超时频发。
常见错误现象：db.Offset(499999).Limit(20) 在压测中触发数据库超时；同一页刷新两次，返回顺序不一致，甚至漏掉某条记录。
- 必须加
Order("id ASC")或Order("created_at DESC, id DESC")，否则无序结果不可重现 -
Offset值不能由前端直接传入，要校验page >= 1且pageSize在 1–100 之间 - 别在
Count()查询里复用带Limit/Offset的 DB 实例，它会忽略这些条件
游标分页怎么写才不重复、不漏、不报错
游标分页本质是“基于上一页最后一条记录的排序字段值继续往后取”，绕开 OFFSET 的物理扫描缺陷。但写错一个细节，就可能返回空结果或重复数据。
- 首排序字段必须有索引、非空、高基数（
id最稳；created_at在高并发下需加id兜底） - 首次请求：不带游标，
db.Order("id ASC").Limit(21).Find(&users)（多查 1 条判断是否有下一页） - 后续请求：用上一页最后一条的
id，db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 前端必须传
last_id（不是页码），后端不做转换；若last_id非法（如负数、非数字），应返回 400 而非静默处理 - 避免字符串拼接游标值；URL 中的
last_id若经 base64 编码，解码要用base64.RawURLEncoding.DecodeString，防止+或/被误解析
Count 总数查询为什么不准还慢
db.Where("status = ?", "active").Limit(20).Offset(40).Count(&total) 这种链式调用，Count 会忽略前面的 Limit 和 Offset，但**不一定忽略 Where** —— 实际行为取决于 GORM 版本和 session 复用逻辑，极易出错。
- 简单场景：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total)隔离会话，避免污染 - 复杂关联（含
Joins或子查询）：手写子查询，db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE p.active = ?) AS t", true).Scan(&total) - 如果 UI 不强制显示“共 XX 条”，就别查总数——省一次全表扫描，QPS 能翻倍
- 缓存总数量只适用于低频变更的数据（如后台配置列表），用户动态数据缓存反而引入一致性风险
索引与 SELECT 字段选择直接影响分页吞吐
当 SELECT * 遇上深分页，MySQL 不仅要扫描大量主键，还要回表查所有字段，I/O 放大数倍。尤其在没有覆盖索引时，性能断崖式下跌。
- 为游标分页字段建联合索引，严格匹配排序顺序：如
ORDER BY status, created_at DESC, id DESC，对应索引为INDEX idx_status_created_id (status, created_at, id) - 避免
SELECT *，只查必要字段；GORM 中可用Select("id,name,created_at")控制返回列 - 即使加了
id索引，OFFSET仍需在 B+ 树里逐节点跳转，无法直接定位——这是索引本身的设计限制，不是没建对 - 高并发下，同一
OFFSET查询可能因 MVCC 版本不同返回不一致结果；游标分页天然规避该问题
真正卡住高并发分页的，从来不是 Go 代码写得不够“优雅”，而是 SQL 执行路径没绕开数据库引擎的硬约束。游标值怎么生成、索引怎么建、总数要不要查——每个选择都直接决定接口能否扛住 1000 QPS。
