gorm无内置分页，需用limit/offset手动实现；echo通过结构体query tag绑定校验分页参数，须兜底默认值、严格校验范围；offset必须在limit前调用且公式为(page-1)*pagesize；总数查询需新建db实例避免受limit/offset影响；order by不可省略，游标分页更适大数据量。
GORM 没有内置分页方法，Paginate 是第三方插件提供的，不是 GORM 自带的——直接用 Limit 和 Offset 最稳，也最不容易翻车。
怎么用 Echo 绑定并校验分页参数
Echo 的 Bind 方法能统一处理 query、form、json 等来源的参数，比手动 c.QueryParam("page") 更安全。关键是要结构体字段带 query tag，并做基础校验。
- 定义结构体时用
query:"page"和query:"limit"显式声明来源，避免绑定错位 - 用
binding:"required,gte=1,lte=100"强制 page ≥ 1、limit 在 1–100 之间，超限就返回 400，不默默截断 - 空值或非数字（如
page=abc）会触发Bind报错，必须显式捕获并响应，不能忽略 error - 别依赖前端传的默认值，后端要主动兜底：即使没传
page，也要设为 1；没传limit就用配置里的默认值（比如 20）
为什么 Offset 必须在 Limit 前调用
虽然 GORM v2 中 Offset 和 Limit 顺序互换也能跑，但语义上 Offset 是“先跳过”，Limit 是“再取多少”，顺序颠倒容易让人误读逻辑。更重要的是，某些旧版驱动或自定义 Scope 可能严格依赖调用顺序。
- 写成
db.Offset(n).Limit(m)是明确且兼容性最好的写法 -
Offset((page - 1) * pageSize)才是正确算式，page=1时Offset(0)，不是Offset(1) - 传负数给
Offset会 panic，所以page校验必须在计算前完成 -
Limit(0)在 SQLite 下可能返回全表，在 MySQL 下可能报错，务必保证pageSize > 0
总数查询为什么不能和分页共用一个 *gorm.DB 实例
Count() 会复用前面链式调用中所有的 Where、Joins、甚至 Limit 和 Offset —— 这是高频踩坑点。你写 db.Where(...).Limit(10).Offset(20).Count(&total)，得到的 total 是“满足条件且被 limit+offset 截断后的行数”，永远 ≤10。
- 总数查询必须新建上下文，推荐用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total) - 如果用了
Preload或复杂Joins，Count容易出错，此时应手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users WHERE ...) t").Scan(&total) - 别把总数和列表查塞进同一个事务里——两次查询之间若数据变更，总数和当前页数据可能对不上，业务是否容忍这点要提前确认
ORDER BY 不加会漏数据，不是性能问题而是语义错误
无序分页在并发写入场景下必然不稳定。数据库不承诺无 ORDER BY 查询的行序，同一请求多次执行可能跳过或重复记录，这不是 GORM 的 bug，是 SQL 标准行为。
- 必须显式加
.Order("id ASC")或.Order("created_at DESC, id DESC")，主键或时间戳+主键组合最可靠 - 只写
.Order("created_at DESC")很危险：当多条记录时间相同时，排序结果不确定，分页边界就会漂移 - 别为了省一个字段或“看起来快一点”而省略
ORDER BY，这是拿数据一致性换毫秒级延迟，得不偿失 - 如果用游标分页（推荐大数据量场景），
ORDER BY字段还必须有覆盖索引，否则性能照样崩
最容易被忽略的是：OFFSET 分页在数据量大了之后，OFFSET 100000 不是慢在 Go 或 GORM，而是数据库要扫描并丢弃前 10 万行——这时候换游标分页不是“优化选项”，而是必选项。
