支付流水对账必须手写 Limit + Offset + 显式 Order，因 Paginate 非 GORM 内置且第三方插件易引发错漏；需加确定性排序（如 Order("created_at DESC, id DESC")）防并发乱序；Count 必须隔离 DB 实例或手写子查询；超 5 万偏移量须切游标分页；Preload 前须完成参数校验。
支付流水对账场景下，GORM 不能直接用 Paginate 方法做分页——它不是 GORM 内置函数，且第三方插件在高一致性要求的金融类查询中容易掩盖参数错误、复用链式条件、漏查总数，导致对账结果错漏。
为什么支付流水必须手写 Limit + Offset + 显式 Order
对账接口需要精确比对两套系统（如银行侧 vs 自建账务）的流水记录，任何一条漏查、重复或顺序错乱都可能引发资金差错。而 Limit/Offset 组合只有配合确定性排序才能保证分页边界稳定：
- 不加
Order("id ASC")或Order("created_at DESC, id DESC")，MySQL/PostgreSQL 返回顺序不可控，同一页请求两次可能拿到不同集合 - 支付流水常含并发插入（退款、补单、冲正），仅靠时间字段排序（如
Order("created_at DESC")）会导致时间相同记录顺序随机，必须加id DESC作为二级排序 -
Offset值由(page - 1) * pageSize计算得出，但 page 必须 ≥ 1、pageSize 必须 ∈ (0, 100]，否则Offset(-1)会 panic，Limit(0)在 SQLite 下可能返回全表
Count 查询必须隔离 DB 实例，否则总数永远不准
对账需返回总条数用于校验“是否全部拉完”，但 db.Where("status = ?", "success").Limit(20).Offset(40).Count(&total) 得到的 total 永远 ≤ 20——因为 Count() 会继承前面的 Limit 和 Offset。正确做法是另起一个干净实例：
countDB := db.Session(&gorm.Session{NewDB: true})
countDB.Model(&PaymentLog{}).Where("status = ?", "success").Count(&total)
- 别用同一个
*gorm.DB链反复调Count和Find，中间若有数据变更，总数和当前页数据就对不上 - 复杂条件（如 JOIN 账户表查用户名称）时，
Count更容易出错，建议改用手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM payment_logs WHERE status = ?) t", "success").Scan(&total) - 如果对账不要求总页数（如只校验增量），可查
pageSize + 1条，用len(results) > pageSize判断是否有下一页，省掉 COUNT 开销
Offset 超过 5 万时，必须切游标分页
支付流水表通常按月分区，单表超千万行很常见。当对账拉取历史全量数据（如查 2025 年全年流水），Offset(500000) 会让 MySQL 扫描并丢弃前 50 万行，响应从 20ms 拉到 3s+，且结果仍可能因写入抖动漏记录。此时应强制切换游标分页：
- 前端首次请求不带游标，后端查
ORDER BY id ASC LIMIT 20，返回last_id字段 - 后续请求传
cursor=123456，SQL 改为WHERE id > ? ORDER BY id ASC LIMIT 20，避免 OFFSET - 排序字段必须有索引，
id最稳妥；若用created_at，必须搭配id构成联合索引（如INDEX(created_at, id)），且查询条件要覆盖索引最左前缀 - 游标分页不能混用
Preload，关联的交易明细、账户信息应分两步查：先取主键列表，再用IN批量加载
最容易被忽略的点：Preload 分页和参数校验的耦合风险
对账时常需关联查用户、商户、渠道等维度信息，但 db.Preload("Merchant").Limit(20).Offset(0).Find(&logs) 表面正常，实际会先查 20 条流水，再为每条发一条 SELECT * FROM merchants WHERE id IN (?, ?, ...) —— 这没问题；但若 Preload 的是“一对多”关系（如每个流水对应多笔手续费明细），GORM 会加载远超 20 条的明细数据，且无法控制每笔流水只取最新 1 条。更危险的是，一旦前端传了非法 page=abc，ShouldBindQuery 失败后若没 return，后续 Offset 可能用零值，导致全表扫描。
- 参数解析必须在 Preload 前完成，且校验失败立即中断：用
c.ShouldBindQuery(&p)，检查p.PageNum 或 <code>p.PageSize 后直接 <code>c.AbortWithStatusJSON(400, ...) - 涉及金额、状态等关键字段的 WHERE 条件，必须和 Count 查询完全一致，包括空字符串处理（如
status != ""）、时间范围截断（start_time默认设为 30 天前） - 日志里打 SQL 时别打完整语句（防敏感字段泄露），至少过滤掉
WHERE amount类条件
