Limit和Offset是GORM唯一稳定、全版本兼容的分页手段；需强校验page≥1、pageSize∈(0,100]，显式Order排序，总数查询须独立db实例，大偏移量应切游标分页。
Limit 和 Offset 是 GORM 唯一稳定、全版本兼容的分页手段——别找 Paginate，它不是 GORM 内置方法，是第三方封装，容易掩盖参数错误、破坏排序语义、且在 GORM v2.6+ 后频繁静默失效。
怎么写才不 panic 或查出全表
传给 Offset 和 Limit 的值必须经过强校验，否则 Offset(-1) 直接 panic，Limit(0) 在 SQLite 下会返回全表，MySQL 可能报错或行为不一致。
-
page小于 1 时强制设为 1，不拒请求也不报错（用户点错页码很常见） -
pageSize必须 > 0 且 ≤ 100（硬限制防 DOS），超出就截断，比如min(p.PageSize, 100) - 用
strconv.Atoi前先判空：q := c.Query("page"); if q == "" { page = 1 }，避免空字符串转整数失败 - 别用
c.ShouldBindQuery(&p)就完事——它只做类型转换，不拦page=0或page_size=999999，得手动补校验逻辑
为什么没加 Order 的分页结果每次都不一样
数据库对无序查询不做行序保证。并发写入、MVCC 版本切换、索引扫描路径变化都会导致同一条 Limit 查询返回不同记录——这不是 bug，是 SQL 标准行为。
- 必须显式调用
Order("id ASC")或Order("created_at DESC, id DESC")，二级排序兜底防时间重复 - 排序字段必须有索引，否则
ORDER BY created_at可能触发 filesort，拖慢分页 - 别用
Order("RAND()")做“随机分页”，它无法翻页，且性能随数据量指数恶化 - 前端传
desc=true时，后端应统一转成Order("created_at DESC, id DESC")，而不是拼字符串，防 SQL 注入
总数 Count 总是不准的三个原因
db.Where(...).Limit(20).Offset(100).Count(&total) 返回的永远 ≤ 20——因为 Count 复用了链上的 Limit 和 Offset，这是最常被忽略的 GORM 行为陷阱。
- 简单场景：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total)隔离会话 - 带
Joins或复杂Where时，Count不继承关联条件，得手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE p.active = ?) AS t", true).Scan(&total) - 如果业务允许（如无限滚动），可跳过
Count，改查pageSize + 1条，用 len(results) > pageSize 判断是否有下一页
什么时候必须切游标分页
当 Offset 超过 10 万，或响应时间开始明显波动（比如从 20ms 涨到 800ms），说明数据库已在真实扫描并丢弃前 N 行——这不是 Go 层能优化的，是 MySQL/PostgreSQL 的物理执行机制决定的。
立即学习“go语言免费学习笔记（深入）”；
- 游标分页依赖确定性排序，首选
id ASC；若用时间字段，必须加id二级排序：Order("created_at DESC, id DESC") - 首次请求：
db.Order("id ASC").Limit(20).Find(&users)；后续请求：db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 前端必须透传
last_id（不是page），后端不做任何转换，非法值（如负数、非数字）直接 400 - 别在游标分页里用
Preload，关联数据要分两步：先查主键列表，再用IN批量加载，否则会漏数据或 N+1
