gorm默认limit/offset分页在财务报表结算场景下极易性能雪崩，必须禁用；应优先采用基于主键/时间戳的游标分页，配合where+order+limit实现无状态、可中断、低延迟流式读取。
直接说结论：GORM 默认的 Limit/Offset 分页在财务报表类大批次结算场景下极易触发性能雪崩，必须禁用；真实生产环境应优先采用基于主键/时间戳的游标分页，配合 Where + Order + First 组合实现无状态、可中断、低延迟的流式读取。
为什么 LIMIT OFFSET 在结算数据分页中会崩
财务报表结算常涉及单次拉取数万至百万级历史记录（如“2025全年交易流水”），若使用 db.Offset(50000).Limit(100)：
- MySQL/PostgreSQL 仍需扫描前 50000 行并丢弃，IO 和 CPU 开销线性增长
- GORM 不会自动帮你加索引 —— 如果排序字段（如
created_at）没建索引，查询会退化为全表扫描 - 事务中长时间持有游标，容易与后续 DDL（如加字段）冲突，引发
Waiting for table metadata lock - 分页参数不可靠：若中途有新数据插入或删除，
OFFSET=50000可能跳过或重复某条结算记录，破坏对账一致性
用 GORM 实现安全的游标分页（PostgreSQL / MySQL）
核心是放弃页码概念，改用“上一页最后一条的 ID 或时间戳”作为下一次查询起点。假设模型为：
type SettlementRecord struct {
ID uint64 `gorm:"primaryKey"`
OrderID string `gorm:"index"`
Amount float64
Status string `gorm:"index"`
CreatedAt time.Time `gorm:"index"`
}
推荐写法（带防重、防漏、可中断）：
- 首次查询：按
CreatedAt升序，取最小 ID 为游标起点：db.Where("status = ?", "settled").Order("created_at, id").Limit(1000).Find(&records) - 后续查询：用上一批最后一条的
created_at和id构造边界条件：db.Where("status = ? AND (created_at > ? OR (created_at = ? AND id > ?))", "settled", last.CreatedAt, last.CreatedAt, last.ID).Order("created_at, id").Limit(1000).Find(&records) - 务必给
(created_at, id)建联合索引，否则WHERE条件无法高效走索引 - 不要依赖
SELECT * FROM ... ORDER BY created_at LIMIT 1000 OFFSET ?—— GORM 的Offset会原样透传 SQL，不解决根本问题
GORM 查询时容易被忽略的三个硬坑
财务类数据对精度和一致性零容忍，以下三点不处理，迟早出对账差错：
-
Timezone配置缺失：PostgreSQL 默认用 UTC，但结算时间常按本地时区（如Asia/Shanghai）生成。DSN 中漏写TimeZone=Asia/Shanghai，会导致created_at > '2025-01-01'实际查的是 UTC 时间，漏掉一整批当日数据 - 未启用
AsNoTracking：结算读取是纯只读场景，db.Unscoped().AsNoTracking().Where(...).Find(...)可减少 40%+ 内存分配，避免 GORM 持有脏状态干扰后续事务 - 外键关联滥用：如结算记录关联
User表，用Preload会触发 N+1 或一次性加载全部用户数据。正确做法是用Select("user_id")先取 ID 列，再用map[uint64]*User批量查一次，或直接用Joins("JOIN users ON ...").Select("settlements.*, users.name")控制字段粒度
游标分页不是加个参数就能跑通，它要求你明确每条记录的全局唯一排序依据、严格索引覆盖、以及对时区/事务隔离级别的显式控制 —— 这些细节一旦松动，在千万级结算数据里，错一条就是财务事故。
