limit+offset分页在fiber+gorm中易因参数未校验、缺order by、preload滥用导致panic、跳条、n+1等线上问题，须手动转参、加索引、用游标、拆关联查询。
直接用 Limit + Offset 在 Fiber + GORM 项目里做分页，能跑通但容易在高并发或大数据量下翻车——这不是配置问题，是 SQL 分页模型本身的限制。
为什么 Limit/Offset 在 Fiber 中必须手动校验 page 和 pagesize
因为 Fiber 不像 Gin 那样默认做 query 绑定校验，c.Query("page") 和 c.Query("page_size") 返回的都是字符串，不转不判就直接进 Offset，极易 panic 或查出意外结果：
-
page为空或负数 →Offset(-1)触发 GORM panic（v2.2+ 默认行为） -
page_size为 0 或负数 →Limit(0)在 MySQL 下可能返回全表，在 SQLite 下行为不一致 - 没设
ORDER BY→ 同一查询多次执行结果顺序可能不同，分页“跳条”或“重复”
实操建议：
用 strconv.Atoi 转换后强制兜底：page := utils.ParseInt(c.Query("page"), 1)，其中 ParseInt 内部处理空值/非法值并返回默认值；pageSize := utils.ParseInt(c.Query("page_size"), 20)，且在 Limit 前加 if pageSize 。
Count 查询必须独立，不能复用主查询链式调用
GORM 的 Count 是单独语句，和 Find 无共享上下文。常见错误是写成：
db.Where("status = ?", 1).Order("id DESC").Limit(10).Offset(0).Count(&total)
这实际只统计了 limit 后的 10 条，不是全量符合条件的总数。
正确做法是拆开：
- 先用
db.Model(&User{}).Where("status = ?", 1).Count(&total)拿总数 - 再用
db.Where("status = ?", 1).Order("id DESC").Limit(pageSize).Offset((page-1)*pageSize).Find(&users)查数据 - 注意
Model(&User{})必须显式指定结构体，否则 Count 可能误算其他表
游标分页比传统分页更适合 Fiber 高频 API 场景
Fiber 常用于构建实时性要求高的后台 API（如客服消息流、订单状态推送），这类场景下 Offset 分页会随写入变慢、漏数据。游标分页用上一页末尾的 id 或 created_at 做条件，性能稳定：
- 前端传
cursor=12345（上一页最后一条记录的主键），后端查WHERE id > 12345 ORDER BY id ASC LIMIT 20 - 避免
OFFSET扫描，百万级表也能毫秒响应 - 需确保排序字段有索引（
id通常自带，created_at需手动建） - Fiber 路由中可统一拦截
cursor参数，与page逻辑隔离，避免混用
示例片段：
var users []User<br>if cursor := c.Query("cursor"); cursor != "" {<br> id, _ := strconv.ParseUint(cursor, 10, 64)<br> db.Where("id > ?", id).Order("id ASC").Limit(20).Find(&users)<br>} else {<br> // fallback 到 page/offset 逻辑<br>}
别在分页查询里用 Preload 加载一对多关联
这是 Fiber + GORM 项目上线后最常被忽视的性能黑洞。例如：
db.Preload("Orders").Limit(20).Offset(0).Find(&users)
表面查 20 个用户，实际会触发 N+1 查询：先查 20 个 user.id，再对每个 id 发一次 SELECT * FROM orders WHERE user_id = ?，最终加载几百甚至上千条订单记录。
更糟的是，你无法控制每个用户的订单数量（比如只想取最新 3 个）。解决路径只有两条：
- 拆成两步：先查用户 ID 列表 → 拼
IN子句查订单 → 手动关联（适合订单量可控） - 改用
Joins+Group By+ 窗口函数（如 PostgreSQL 的ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)），但跨数据库兼容性差
真实项目里，多数情况应放弃“一页带关联”的幻想，让前端分两次请求：先拉用户列表，再按需查某个用户的详情和最近订单。
分页看着简单，但在 Fiber 这种轻量高性能框架里，每一步都得抠 SQL 行为、参数边界和关联加载策略——尤其是 Count 和主查询分离、游标替代 Offset、Preload 的陷阱，三者漏掉任一个，线上查慢或数据错乱就是分分钟的事。
