分页

只有一套：keyset 游标。全站没有 offset。

GET /v1/remittances?limit=50&cursor=eyJ0IjoiMjAy…

{
  "data": [ … ],
  "next_cursor": "eyJ0IjoiMjAy…",
  "has_more": true
}

三条纪律

一、翻到底的判据是 has_more，不是 data.length < limit。

后者在最后一页正好装满时会让你少翻一页。

二、next_cursor 是不透明串，不要解析它。 它现在是 base64 的

(排序值, id) 二元组，但这是实现细节；解开它拼一个自己的游标，

在我方换排序键的那天会静默错位。

三、解不开的游标从头开始，不报错。 你传一个过期或损坏的 cursor 拿到的是

第一页，不是 400 —— 因为「翻页翻到一半我方发版了」不该让你的批处理中断。

副作用是：如果你自己拼错了游标，表现是「怎么又从头开始了」而不是报错。

为什么不给 offset

订单表按 created_at DESC 翻页时新数据插在前面。offset=100 在第二次请求时

指向的已经不是同一行了 —— 结果是漏行 + 重行，而两者都不报错，

只表现为「导出的账对不上，差几条」。

静态清单

少数端点（如 GET /v1/transfers/recipient-types）的结果集是有界的常量表，

它们照样返回同一个信封：

{ "data": [ … ], "next_cursor": null, "has_more": false }

这样你的通用翻页器不需要为它们开特例。