GORM分页必须用Limit+Offset不准确，官方推荐手写Limit+Offset或游标分页；需校验page≥1、pageSize∈(0,100]，显式Order排序，总数查询须独立db实例，大偏移量应切游标分页。
分页参数怎么从 Gin 请求里安全取出来
直接用 c.Query("page") 和 c.Query("limit") 拿字符串再转整型，容易 panic 或返回 0 —— 比如用户传 page=abc 或 limit=-10，cast.ToInt() 会默默转成 0，后面计算 (page-1)*limit 就变成 0，查出全表数据，线上可能直接拖垮数据库。
更稳妥的做法是显式校验并设默认值：
- 用
c.DefaultQuery("page", "1")和c.DefaultQuery("limit", "20")避免空值 - 转整型后立刻判断范围：
if page ，<code>if limit 100 { limit = 20 } - 不要依赖第三方 cast 包做“静默容错”，它掩盖了非法输入问题
GORM 分页必须用 Limit+Offset 吗
不是。虽然 Limit() + Offset() 最直观，但对大偏移量（比如第 10000 页）性能极差：MySQL 仍要扫描前 9999×20 行才开始返回。实时聊天场景下，历史消息通常按时间倒序，更适合用「游标分页（cursor-based pagination）」。
关键点：
- 游标分页依赖上一页最后一条消息的
created_at和id（联合去重），查询条件写成WHERE created_at - GORM 不支持原生游标语法，得手写
Where()拼条件，不能依赖Offset() - 必须给
(created_at, id)建联合索引，否则照样慢 - 前端需保存上一页最后一条的
created_at和id，作为下一次请求的游标参数
为什么分页结果总少一条或多一条
常见原因是没处理好「时间精度」和「并发插入」。比如用 created_at 做游标时，如果两条消息毫秒级时间相同，只靠 created_at 排序无法稳定确定顺序，下一页可能漏掉或重复某条。
解决办法很实际：
- 模型字段加
gorm:"index:idx_created_at_id,order:desc"，强制按created_at DESC, id DESC排序 - 查询时明确写
Order("created_at DESC, id DESC")，别依赖 GORM 默认行为 - 游标参数必须同时传
last_created_at和last_id，WHERE 条件严格按「时间更早，或时间相等但 ID 更小」构造 - 避免用
time.Now().Unix()做时间戳，改用数据库生成的created_at字段值，防止客户端和服务端时钟偏差
Count 总数在实时聊天里要不要查
绝大多数情况下——不要查。实时聊天的历史列表，用户根本不在乎「总共多少页」，只关心「还能不能再往上翻」。每次分页都执行 Count()，等于多一次全表扫描或索引遍历，QPS 上去后就是瓶颈。
替代方案更轻量：
- 查当前页数据时，多取 1 条（比如 limit=20，实际查 21 条），如果返回 21 条，说明还有下一页；否则就是最后一页
- 前端用「加载更多」按钮代替页码控件，状态由后端响应体里的
has_more: true控制 - 真需要总数（比如管理后台），单独提供带缓存的统计接口，不和分页共用同一个 SQL
游标分页本身就不适配总数统计，硬查 Count() 还会破坏它的性能优势。
