分页前必须校验并归一化page和page_size：page≤0时强制设为1，page_size硬限制1–100并截断；须用结构体绑定+ShouldBindQuery校验，禁用裸strconv.Atoi；总数查询需独立会话或子查询；必须显式Order排序；大数据量应改用游标分页。
分页前必须校验并归一化 page 和 page_size
前端传来的 page 和 page_size 不能直接参与计算。常见错误是 strconv.Atoi(c.Query("page")) 后不做判断，导致 page=0 算出 Offset(-1)，GORM 会静默忽略或触发 panic；page_size=10000 则可能拖垮数据库。
实操建议：
-
page小于等于 0 时强制设为 1 -
page_size必须硬限制（如上限 100），超出则截断：limit := min(p.PageSize, 100) - 用结构体 +
c.ShouldBindQuery(&p)统一校验，比手动c.Query()更安全 - 避免在 URL 中暴露
offset参数——它不是业务语义，而是实现细节，容易被滥用
动态字段过滤要拼 WHERE 条件，别复用同一个 *gorm.DB
带搜索的分页，比如按 name LIKE ? 或 status = ? 过滤，必须在分页查询前动态加 Where()，但千万不能让总数查询和列表查询共用一个 *gorm.DB 实例。
常见错误现象：db.Where("name LIKE ?", "%a%").Limit(10).Offset(0).Count(&total) 返回的 total 是 10，不是符合条件的总条数——因为 Limit 已生效。
实操建议：
- 总数查询必须新建会话：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total) - 复杂 JOIN 场景下，
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) - 过滤字段若来自用户输入（如
field=name&value=xxx），需白名单校验，禁止传password、deleted_at等敏感字段名
ORDER BY 不是可选项，是分页稳定性的前提
没有 Order() 的分页结果不可预测：同一页刷新两次，可能漏掉某条记录，也可能重复出现。这不是 GORM 的 bug，而是 MySQL/PostgreSQL 在无序 LIMIT 下不保证返回顺序。
实操建议：
- 必须显式调用
Order("id ASC")或Order("created_at DESC, id DESC") - 排序字段必须有索引；如果用
created_at，务必加二级排序（如id DESC），避免时间相同导致顺序漂移 - 禁止
Order("RAND()")——无法翻页，且性能极差 - GORM v2 中
Offset().Limit()和Limit().Offset()都能工作，但为兼容性，建议固定写成Offset().Limit()
大数据量下 OFFSET 分页会失效，游标分页才是正解
当表行数超 50 万，OFFSET 100000 查询开始明显变慢，甚至超时。这不是 Go 层能优化的，是 MySQL 扫描并丢弃前 N 行的固有代价。
实操建议：
- 对「最新消息」「订单流」等天然有序场景，改用游标分页：前端传上一页最后一条的
id和created_at，后端查WHERE id > ? ORDER BY id LIMIT 20 - 游标分页无需总数，可只返回
has_next: true，查size + 1条来判断 - 如果业务强依赖总页数（如后台管理），且数据量不大（WHERE 条件能命中索引
- 别指望 GORM 自动把 OFFSET 转成游标——它只是 SQL 拼接器，逻辑得自己写
最常被忽略的一点：分页和过滤的组合，本质是「先过滤、再排序、最后切片」三步不可拆。任何一步缺失（比如忘了 Order、或 Count 复用了链式 DB），都会在高并发或大数据时突然暴露问题，而且很难复现。
