offset分页在群组列表中必然失败，因其依赖静态物理行序而非动态逻辑顺序：新群组创建、旧群组解散或私密化会导致offset跳过或重复数据；高偏移量引发全表扫描、i/o与cpu开销线性增长；mysql需丢弃前n行，postgresql易触发tuple可见性阻塞；且offset无法感知逻辑删除，造成页错位。
高吞吐量即时通讯场景下，群组列表分页不能用 Limit + Offset——它会在 page > 50 时开始丢消息、重复返回、响应超时，且无法应对群组频繁创建/解散的实时性要求。
为什么 Offset 分页在群组列表里必然失败
群组列表不是静态数据：新群组持续创建，旧群组可能被解散或设为私密，OFFSET 对应的是数据库扫描时的物理行序，不是逻辑“第 N 个群组”。一次分页请求耗时 200ms，期间已有 3 个新群组插入，那么第 2 页就可能跳过其中 1 个，或在第 3 页又出现。
- MySQL 中
OFFSET 10000实际要扫描并丢弃前 10000 行，CPU 和 I/O 开销线性增长 - PostgreSQL 的
OFFSET在高并发下易触发tuple visibility check阻塞，导致查询排队 - 前端下拉加载时传
page=100，后端直接执行OFFSET 9900，DB 连接池迅速打满 - 用户退出群组后，该群组从列表中消失，但
OFFSET不感知逻辑删除，导致后续页错位
必须用游标分页：基于 created_at + id 的双字段排序
游标分页不依赖页码，只依赖上一页最后一条记录的锚点值，天然规避偏移漂移。即时通讯群组必须按创建时间倒序展示，所以锚点字段选 created_at DESC, id DESC（避免同一秒创建多个群组时 created_at 冲突）。
- 首次请求不带游标：
db.Order("created_at DESC, id DESC").Limit(20).Find(&groups) - 响应体必须返回
next_cursor，例如"2026-08-21T12:34:56Z_12345"（拼接最后一条的created_at字符串和id） - 下一页请求解析游标：
WHERE created_at ，参数填入解析出的时间与 ID -
created_at字段必须建复合索引：INDEX idx_created_id (created_at, id)，否则查询走全表 - 禁止在游标分页中用
Preload("Members")——先查群组 ID 列表，再用IN批量查成员，否则 N+1 问题会放大 20 倍
Count 查询必须砍掉，前端改用「无总数」滚动加载
即时通讯群组列表没人真看“共 XXX 页”，用户只关心“还能不能往下拉”。硬查 COUNT(*) 在千万级群组表上是 DB 的定时炸弹，且结果在返回瞬间就已过期。
- 删掉所有
db.Model(&Group{}).Count(&total)调用，Gin 接口响应里不返回total或pages - 前端用
next_cursor != ""判断是否显示“加载更多”，而不是current_page - 如果业务强依赖总数（如后台管理），单独开一个低频定时任务，用
SELECT COUNT(*) FROM groups WHERE status = 'active'写入 Redis 缓存，TTL 设为 30 分钟 - 千万别把 Count 查询和主查询塞进同一个
*gorm.DB链——Count()会继承前面的Limit/Offset，返回永远是 20
真实部署时最容易被忽略的三个点
游标分页逻辑写对只是第一步；线上出问题，八成卡在这三处。
- 时间字段必须用 UTC 存储并比较：若数据库
created_at是TIMESTAMP类型但应用层用本地时区写入，游标解析后时间错位，直接漏群组 - 游标字符串拼接必须 URL-safe：
created_at里的冒号、空格、+ 号要url.PathEscape，否则前端传回来 400 - GORM 查询必须显式加
Unscoped()吗？不。群组软删除（deleted_at）需在 WHERE 条件里显式过滤：WHERE deleted_at IS NULL AND (created_at ，否则游标会跨过已删除记录造成断层
