在kratos中用gorm分页应手写limit+offset，因其逻辑清晰、全版本兼容、避免插件陷阱且便于链路追踪；需校验page≥1、pagesize>0、单独查total；pageresult结构体应含items、total等字段并用interface{}泛化。
在Kratos中用GORM做分页，不能依赖 Paginate 这类第三方封装——它不是GORM内置方法，且容易因版本不匹配导致 Offset 计算错误或漏数据。
为什么直接用 Limit + Offset 是最稳妥的选择
GORM官方明确推荐手写 Limit 和 Offset 实现分页，原因很实在：
-
Offset((page - 1) * pageSize)逻辑清晰、无隐藏行为，调试时一眼能看懂执行计划 - 所有GORM v2.x 版本都兼容，不依赖插件更新节奏（比如
gorm/pagination在 v2.2.0+ 后已不再维护） - 避免插件自动拼接
COUNT查询带来的事务/上下文陷阱（例如在Kratos的context.Context中未透传超时，COUNT查询卡住整个接口） - Kratos服务常需对接监控和链路追踪，手写分页便于在
db.WithContext(ctx)中统一注入 traceID
GORM分页必须校验的三个边界条件
在Kratos的 internal/data 层实现分页时，这几个检查点漏掉一个就可能在线上返回空数组或 panic：
-
page必须 ≥ 1：若前端传page=0，Offset(-10)会触发 panic，建议在 service 层或中间件提前拦截 -
pageSize必须 > 0：Limit(0)在 SQLite 下等价于无限制，在 MySQL 下返回空结果，行为不一致 - 总记录数必须单独查：不能复用带
Limit的查询，db.Model(&User{}).Count(&total)是唯一可靠方式；注意别在同一个tx里复用，否则可能读到未提交数据
Kratos中分页结果结构体怎么设计才不踩坑
很多团队直接返回 []*User，但分页接口必须带元信息。建议在 internal/biz 层定义统一结构体：
type PageResult struct {
Items interface{} `json:"items"`
Total int64 `json:"total"`
Page int `json:"page"`
PageSize int `json:"page_size"`
PageCount int `json:"page_count"` // 可选，由 Total / PageSize 推导
}
关键点：
-
Items用interface{}而非具体切片类型，方便复用（比如User、Order共用同一分页封装） - 不要在
data层做json.Marshal，交给 transport 层（HTTP/gRPC）处理序列化 - 如果用了 Kratos 的
metadata传递分页参数，记得在 service 层从ctx提取并校验，而不是全靠 HTTP query string
关联预加载（Preload）和分页一起用时的典型陷阱
在Kratos的 repo 方法里写 r.db.Preload("Orders").Offset(...).Limit(...).Find(&users) 看似自然，但实际会引发 N+1 或数据膨胀：
- GORM 先查出 10 个用户，再发一条
SELECT * FROM orders WHERE user_id IN (1,2,...,10)—— 这可能拉回几百条订单，远超预期 - 无法控制每个用户的订单数量（比如“只取每个用户最新 3 条订单”），
Preload不支持子查询限制 - 正确做法是拆成两步：先分页查用户 ID 列表，再用
IN+ORDER BY created_at DESC LIMIT 3子查询加载关联数据，或改用Joins+Group手写 SQL
分页真正的复杂点不在语法，而在于它把数据库、ORM、上下文、传输层全串起来了。一个 Offset 算错，可能让监控看到的 P99 延迟突然翻倍；一个没校验的 page=0，可能让前端无限 loading。在Kratos里，越“基础”的操作，越要抠细节。
