gorm分页唯一可靠方式是limit+offset组合，因gorm无原生paginate；offset必须为(page-1)*page_size且page≥1，需校验参数、显式order排序、独立执行count查询。
Limit 和 Offset 是 GORM 分页唯一可靠组合，别找 Paginate 方法——它不是 GORM 内置的，所有“自动分页”封装都只是对这两者的再包装，还可能引入顺序错乱、参数透传失控等问题。
怎么算 Offset 才不翻车
Offset 不是“第几页”，而是“跳过多少条”。第 3 页、每页 20 条，得 Offset(40)，不是 Offset(3)。
- 公式固定为：
(page - 1) * page_size，page必须 ≥ 1，否则Offset(-20)会 panic -
page小于等于 0 时，直接设为 1；别返回错误，用户点错页码很常见 -
page_size为 0 或负数时，Limit(0)在 SQLite 下查全表，在 MySQL 下可能报错，必须拦截 - 用
gin.Context.ShouldBindQuery(&p)绑定结构体比手动c.Query()更安全，能统一做binding:"gte=1,lte=100"校验
为什么 COUNT 总是错得离谱
db.Where(...).Limit(n).Offset(m).Count(&total) 返回的 total 永远 ≤ n —— 因为 Count 复用了前面链式调用里的 Limit 和 Offset，这不是 bug，是 GORM 的设计逻辑。
- 正确做法：用独立会话查总数，
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total) - 复杂 JOIN 或 Preload 场景下，
Count容易因去重或笛卡尔积失真，直接手写子查询更稳：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE ...) AS t").Scan(&total) - 如果业务允许（比如 Feed 流），可只查
page_size + 1条，判断是否有下一页，省掉 COUNT
ORDER BY 不加，分页就不可靠
没 Order 的分页，数据库不保证行序。并发写入时，同一页可能漏掉记录，也可能重复出现——这不是 GORM 的问题，是 SQL 标准行为。
- 必须显式指定，例如
Order("id ASC")或Order("created_at DESC, id DESC") - 避免只用
Order("created_at DESC")：时间字段重复率高，排序结果不稳定 -
Order("RAND()")看似有趣，但无法翻页、性能差、COUNT 失效，生产环境禁用 - 确保排序字段有索引，否则
OFFSET越大越慢，10 万偏移后响应可能从 20ms 拉到 2s+
什么时候该放弃 Offset-Limit
当单表数据超百万、且分页深度常达 10 万+ 行时，Offset 已不是 Go 层能优化的问题，是 MySQL 扫描成本本身决定的瓶颈。
- 游标分页更合适：前端传上一页最后一条的
created_at和id，后端查WHERE created_at - 游标要求排序字段组合唯一、有覆盖索引，且不能跳页（不支持“跳到第 100 页”）
- 别在 Preload 关联查询里用分页：例如
Preload("Orders")后，GORM 会为每条主记录发一次 IN 查询，实际加载订单数远超Limit值，且无法控制每个用户的关联条数
真正容易被忽略的是：分页参数校验必须在 Offset 和 Limit 调用前完成，且 Count 查询和主查询之间若存在数据变更，总数和当前页数据天然不同步——这不是缺陷，是最终一致性场景下的合理取舍。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
