流式分页不能用LIMIT/OFFSET因OFFSET越大扫描成本越高；应改用游标分页，基于排序字段（如id）锚定位置，要求字段有索引且值唯一或组合唯一，并严格校验游标、显式指定WHERE与ORDER字段。
流式分页为什么不能用 Limit/Offset
因为 Offset 越大，数据库扫描成本越高。MySQL 在 OFFSET 100000 时仍要定位并跳过前 10 万行，响应可能从毫秒级升至秒级。这不是 GORM 的问题，是 SQL 执行模型决定的。
流式分页（也叫游标分页）绕开偏移量，靠排序字段值“锚定”位置：上一页最后一条记录的 id 或 created_at 成为下一页查询的起点。它要求排序字段有索引、值唯一或组合唯一。
- 首选
Order("id ASC")：自增主键天然有序、无重复、索引完备 - 次选
Order("created_at DESC, id DESC")：时间可能重复，补id保确定性 - 禁用
Order("status ASC")或Order("RAND()")：无法构造可靠游标
首次请求不带游标参数，查 ORDER BY id ASC LIMIT 20；拿到结果后取 users[len(users)-1].ID 传给前端，下次请求带上 cursor=12345，后端生成 WHERE id > 12345 ORDER BY id ASC LIMIT 20。
如何用 GORM 写安全的游标分页查询
GORM 不提供 PaginateCursor 这类方法，必须手拼 WHERE 条件。关键不是“怎么写 SQL”，而是“怎么防错”：
- 游标值必须校验类型和范围：
cursor是字符串，需strconv.ParseUint(c.Query("cursor"), 10, 64)，失败就返回 400 - WHERE 条件必须显式加索引字段：不能只写
Where("id > ?", cursor)，得和 Order 字段一致，否则索引失效 - 禁止在游标分页中混用
Preload：关联数据应分两步——先查主表 ID 列表，再用Where("user_id IN (?)", ids)批量加载 - 总数查询在此场景下通常省略：游标分页本身不依赖总页数，前端显示“下一页”即可，无需
Count
示例片段：
var users []User
cursor := c.Query("cursor")
if cursor != "" {
id, err := strconv.ParseUint(cursor, 10, 64)
if err != nil {
c.JSON(400, gin.H{"error": "invalid cursor"})
return
}
db.Where("id > ?", id).Order("id ASC").Limit(20).Find(&users)
} else {
db.Order("id ASC").Limit(20).Find(&users)
}
批量导出数据为什么不能用 FindInBatches 直接 JSON 流式响应
FindInBatches 是为“处理后写回”设计的，不是为“边查边吐”。它的 handler 回调里若直接 c.Stream 或 c.SSE，会因 HTTP 连接未关闭、Gin 上下文生命周期结束，导致响应中断或 panic。
- handler 中的
*gorm.DB实例是子事务，不能跨批次复用上下文 - handler 返回 error 会终止后续批次，但不会自动 rollback（GORM 默认非事务）
- 若导出需带关联数据，
Preload在FindInBatches中行为不可控：它会在每批内触发 N+1 查询，且无法限制每条主记录只取前 N 个关联项
真正适合导出的做法是：用 Rows() 获取原始 *sql.Rows，手动迭代并 Scan 到 struct，配合 io.Writer 写 CSV 或 json.Encoder 流式编码。这样内存占用可控，且完全脱离 GORM 的链式构建逻辑。
导出时如何避免 OOM 和超时
10 万行数据一次性 Find(&list) 很容易吃光内存；用 FindInBatches 又可能因 handler 生命周期混乱引发 goroutine 泄漏。稳妥路径是三层控制：
- SQL 层：加
SELECT ... FOR UPDATE？不，导出一般只读，禁用锁；但必须加ORDER BY id防结果漂移 - GORM 层：不用
FindInBatches，改用db.Session(&gorm.Session{PrepareStmt: true}).Raw(...).Rows()获取游标式结果集 - Go 层：用固定大小 buffer（如 1000 条/批），每次
encoder.Encode()后flush，并检查c.Request.Context().Done()应对客户端断连
特别注意：别在 handler 里调 c.AbortWithStatusJSON —— 它会提前终止整个请求，而你正处在流式写入中途。
Rows 控制、以及 context 生命周期管理，这三处最容易被封装层掩盖，也是线上出问题的第一现场。 
