假设你做了一个反馈列表：最新的排在前面，每页三条。第一屏看起来正常，点击下一页，却又看到刚看过的反馈。用户会怀疑加载失败，开发者则可能先去查前端去重。
这个问题值得先从分页语义查起。我在本地用 Python 3.13.5 做了一个列表模拟，数据完全是假数据：初始顺序是 6、5、4、3、2、1，第一页取到 6、5、4。此时插入新记录 7，再按 OFFSET 3 取三条，第二页变成 4、3、2。重复的 4 没有来自网络重试，而是列表位置移动了。
如果产品的意思是“接着上次最后一条往下看”，这个简化场景可以按 id < 4 继续，得到 3、2、1。这里假设 id 唯一、单调递增且顺序不变；这只是算法模拟，没有进行数据库性能测试。
真实系统往往按创建时间排序。同一毫秒有多条记录时，仅 ORDER BY created_at 不够明确，可以加唯一 id 作为最后的排序条件。PostgreSQL 文档强调，LIMIT/OFFSET 要得到可预测的子集，需要约束出唯一顺序；它也提醒较大的 OFFSET 有计算跳过行的成本。
我建议把验收分成三个场景：两条记录时间相同；用户翻页前插入新记录；用户翻页前删除一条记录。每次同时记录第一页末尾的排序键和第二页开头，判断重复或遗漏发生在什么条件下。
游标也不是万能方案。如果排序用“最后活跃时间”，记录会在两次请求之间移动；只加一个游标，并不能把整个列表冻结成快照。若是账单导出这类要求一批数据前后一致的任务，需要另行设计快照或固定数据集。若是后台小表、确实需要跳到第 20 页，OFFSET 仍可能是合理选择。
可以复用的一句需求是：“列表按创建时间和唯一 id 倒序；继续加载从上次末条之后开始；新内容由刷新入口显示。”先让设计、前端和后端同意这句话，再选 SQL，往往比在页面上悄悄删掉重复项更容易定位问题。
资料：PostgreSQL 官方 LIMIT/OFFSET 文档；持续维护页面，未取得页面更新时间。查阅日期：2026-11-06（Asia/Shanghai）。
来源：https://www.postgresql.org/docs/current/queries-limit.html
