limit+offset在聊天场景必然失败，因高频写入导致offset扫描性能骤降且引发消息重复或丢失；必须用created_at+id双字段游标分页，并配合法定复合索引与安全游标编码。
实时聊天历史记录分页拉取不能用 Limit + Offset，因为消息高频写入、用户滚动加载时页码可能跳到几千页，OFFSET 会直接拖垮查询性能并导致重复/丢失。
为什么 Limit+Offset 在聊天场景下必然失败
聊天消息表每秒可能新增数十条，OFFSET 10000 不是“查第 10001 条”，而是让数据库从头扫描并跳过前 10000 行——哪怕有索引，MySQL 仍需回表或遍历索引树；PostgreSQL 在 OFFSET > 10000 后常触发顺序扫描。更致命的是：A 用户发一条新消息，所有正在翻页的用户都可能看到某条消息在两页中同时出现，或彻底跳过它。
- 常见错误现象：
page=200&page_size=20返回空切片，但往前翻一页却有数据 - 前端无限滚动时，用户快速上拉再下拉，同一条消息反复渲染两次
-
Count(&total)结果和实际可拉取页数严重不符，因count是快照，而offset查询是动态扫描
必须用游标分页：基于 created_at + id 的双字段排序
游标分页不依赖物理偏移，而是“从上一页最后一条消息的位置继续往后取”。对聊天消息，created_at 是主排序依据（毫秒级时间戳），id 是第二排序字段（防时间重复）。两者必须联合建复合索引：INDEX idx_created_id (created_at DESC, id DESC)。
- 首次请求不带游标，SQL 等价于：
SELECT * FROM messages WHERE room_id = ? ORDER BY created_at DESC, id DESC LIMIT 20 - 后续请求带
cursor=1724212800123_1005（格式：unix_ms_id），SQL 等价于：SELECT * FROM messages WHERE room_id = ? AND (created_at, id) - GORM 写法示例：
db.Where("room_id = ?", roomID).Where("(created_at, id)
游标值生成与校验不能靠前端传原始时间戳
前端传 created_at 容易被篡改或精度丢失（如 JS Date.now() 是毫秒，数据库存的是微秒或纳秒）；直接拼字符串游标也难做安全校验。正确做法是：后端返回结构化游标，并只接受自己签发的游标。
- 返回游标时，用 base64 编码 + 签名，例如：
base64.StdEncoding.EncodeToString([]byte(fmt.Sprintf("%d_%d", msgs[len(msgs)-1].CreatedAt.UnixMilli(), msgs[len(msgs)-1].ID))) - 解析游标时先校验签名或长度，再拆解，避免 SQL 注入或类型溢出（如
id被传成负数或超大整数） - 如果最后一页不足
page_size，不返回next_cursor，前端据此停止加载
附：GORM 游标分页封装要点
别把游标逻辑塞进通用分页工具函数里——聊天消息的排序方向（DESC）、字段组合（created_at + id）、索引要求、游标编码方式，都和后台管理列表（通常 ASC + id）完全不同。硬套会导致线上慢查询告警。
- 必须显式指定
.Order("created_at DESC, id DESC")，漏掉任一字段或方向都会破坏游标语义 - WHERE 条件中
room_id等过滤字段，必须在游标条件(created_at, id) 之前调用，否则 GORM 可能错乱执行顺序 - 不要复用同一个
*gorm.DB实例做 count 和游标查询；总数统计走单独 SQL：SELECT COUNT(*) FROM messages WHERE room_id = ? AND created_at （注意这里用单字段，且时间范围要和首条游标对齐）
游标分页真正难的不是写 SQL，而是让前后端对“游标是什么”达成一致：它不是页码，不是时间戳，而是数据库中某一行的不可变位置锚点。一旦这个认知偏差存在，再严谨的代码也会在高并发下漏消息。
