GORM在go-zero中不能直接用Paginate，因其官方从未提供该方法，所有封装均为第三方或自研，底层仍是Limit+Offset，且多数缺失参数校验、总数隔离、强制排序等关键防护。
为什么 GORM 在 go-zero 里不能直接用 Paginate
GORM 官方从 v1 到 v2 都没提供 Paginate 方法，所谓“分页封装”全是第三方或自己写的。go-zero 本身也不内置分页逻辑——它只管路由、中间件、RPC 调用和配置加载，数据库分页得你亲手用 Limit 和 Offset 控制。别被某些 demo 里叫 Paginate 的函数名骗了，那只是个名字，底层还是 Limit().Offset()，而且多数没做参数校验、总数查询隔离、排序强制等关键防护。
Limit 和 Offset 的顺序与计算必须严格对齐
在 go-zero 的 service 层（比如 logic 或 dao）写分页时，Offset 必须在 Limit 前调用才符合直觉（虽然 v2 允许互换，但易混淆）。更重要的是：前端传 page=3&page_size=10，后端不能直接 Offset(3)，而要算成 Offset((p.PageNum - 1) * p.PageSize)。
-
page=1→Offset(0)（第 1 条开始） -
page=2→Offset(10)（跳过前 10 条） -
page=0或负数 → 必须拦截并设为 1，否则Offset(-10)可能 panic 或查出全表 -
page_size=0→Limit(0)会返回空 slice 且不报错，但实际是查全表，必须提前截断
总数查询必须独立执行，且不能复用同一个 *gorm.DB 实例
前端需要总条数渲染页码控件，所以你要额外跑一次 SELECT COUNT(*)。但它和主查询是两个 SQL，如果共用一个链式 DB.Where(...).Order(...) 实例，Count() 会把 Order、Limit、Offset 全带上——而 COUNT(*) 不该带这些，会导致结果错误或 MySQL 报错。
- 正确做法：用原始
DB.Model(&User{}).Where(...)构建条件子句，再分别调用Count()和Limit().Offset().Find() - 别写
db := DB.Where(...).Order(...); db.Count(&total); db.Limit(...).Find(&list)—— 这样Count也会被加Order，MySQL 8.0+ 直接报错 - go-zero 的
svcCtx里注入的是*gorm.DB，每次分页都应基于它新建链式调用，避免状态污染
go-zero 中参数校验和默认值处理不能靠 Gin 的 ShouldBindQuery 单独兜底
go-zero 默认用 gin 做 HTTP 层，但它的参数绑定只是第一步。很多项目直接 c.ShouldBindQuery(&p) 后就进逻辑，却忽略了：PageNum 和 PageSize 是 int 类型，前端传字符串如 page=abc 会导致绑定失败（ShouldBindQuery 返回 error），但若没显式检查，可能 fallback 成 0，后续 Offset(0) + Limit(0) 查全表。
- 必须显式判断
err != nil并返回 400，不能忽略或 log 后继续 -
PageSize要和配置上限取min，例如limit := util.Min(p.PageSize, 100)，防止恶意设成 10000 导致慢查询 -
PageNum <= 0时强制设为 1，但注意：不是所有业务都接受page=0自动转 1，有些需明确报错（如审计日志类接口） - 排序字段（如
order_by=id）也得白名单校验，不能让用户传order_by=(SELECT SLEEP(5))这种注入片段
最容易被忽略的点是：分页结果稳定性完全依赖 Order。没显式 Order("id ASC")，MySQL 可能按文件顺序返回，两次请求同一页数据顺序不同，前端翻页时出现重复或丢失。这不是 bug，是数据库规范行为——GORM 不会帮你补这个。
