跨服务分页不能用sql join或offset/limit，因数据物理隔离、网络延迟与状态不一致；应改用游标分页，以业务唯一标识（如订单id）为cursor，避免页码模式。
跨服务分页没法靠单次 SQL JOIN 解决，因为数据物理隔离在不同数据库甚至不同技术栈里；强行用 API 组合 + 内存分页，容易 OOM 或结果错乱——这不是封装技巧问题，是架构约束下的必然取舍。
为什么不能把跨服务分页当成本地多表查询来写
本地数据库的 JOIN ... LIMIT ... OFFSET 是原子操作，数据库能保证排序、去重、偏移全部一致；而微服务间调用是网络通信，两次请求之间数据可能已变更（比如用户服务返回了 ID 列表，订单服务查时部分订单已被删除），导致最终拼出的第 2 页缺记录或重复。更麻烦的是：你无法对远程服务的结果做稳定排序——订单服务按 created_at 排，用户服务按 name 排，谁先谁后？没有全局事务协调，就不存在“一致快照”。
- 常见错误现象：
GetUsersByName("Alice")返回 [101,102,103]，但GetOrdersByUserIds([101,102,103])实际只查到 2 条，Page(2)直接跳空 - 排序字段不统一：前端要求“按订单金额降序”，但金额在订单服务，用户昵称在用户服务，无法在一次 SQL 里完成排序
- 总数统计失真：用户服务说有 50 个匹配用户，订单服务说这 50 人共产生 127 笔订单，但其中 8 笔已软删除——谁负责过滤？在哪过滤？
API 组合模式下分页必须放弃“页码”，改用游标
传 page=3&size=20 在跨服务场景下本质是反模式：它隐含“前两页数据稳定不变”的假设，而这个假设在网络调用中根本不可靠。正确做法是让前端记住上一页最后一条记录的业务标识（如订单 ID 或组合时间戳），下次请求带上 cursor=12345，后端据此向各服务发起带条件的增量查询。
- 首次请求：调用用户服务查出前 20 个匹配用户 ID，再用这批 ID 向订单服务查订单，并按金额排序取前 20 条；返回时附带
cursor=order_98765 - 后续请求：解析
cursor得到上一页最后订单 ID，先查该订单所属用户 ID，再查该用户所有订单中id > 98765的最新 20 条 - 关键限制：游标字段必须有索引、单调、可比较；避免用
created_at单独作游标，高并发下易重复，建议用id或created_at, id复合
GORM 分页封装在跨服务场景下完全失效
Paginate、Scope、Limit/Offset 这些 GORM 原语只作用于单个数据库连接，它们生成的 SQL 无法跨网络边界。试图在订单服务里写 db.Scopes(Page(p)).Preload("User")，只会触发 N+1 查询（先查 20 个订单，再发 20 次 RPC 查用户），且 Preload 的 WHERE 条件无法透传到用户服务，用户服务根本不知道你只要关联字段、不要全量用户数据。
- 别碰
Preload：它在跨服务下既无意义又危险，会放大网络开销 - 别复用
*gorm.DB实例做多次 Count/Find：这是单服务内的状态污染问题，跨服务时连“污染源”都不存在——你压根没机会链式调用 - 总数统计只能近似：要么查用户服务返回匹配数（忽略订单侧过滤），要么订单服务返回“当前批次可见订单数”，二者都不等于真实分页总数
真正可行的折中方案只有两种
一种是接受精度损失，用“服务端聚合 + 客户端截断”：用户服务返回最多 1000 个 ID，订单服务查出这些 ID 对应的所有订单（不限条数），后端内存排序后截取第 N 页；适用于数据量小、一致性要求不高的管理后台。另一种是彻底放弃分页，改用搜索式交互：前端输入关键词，后端返回带高亮的前 50 条匹配结果，加“查看更多”按钮触发新查询——把分页逻辑从服务端转移到用户操作路径上。
最常被忽略的一点：跨服务分页的瓶颈从来不在代码怎么写，而在你是否真的需要它。很多所谓“订单列表页”其实 95% 流量集中在前 3 页，与其花两周搞分布式游标，不如加个缓存层，把 user_name=Alice&page=1 的结果缓存 5 分钟。
