应采用基于主键或时间戳的游标分页，避免Limit/Offset；因Feed流数据按时间倒序且高并发下created_at易重复，须叠加id等唯一字段排序并建复合索引，前端传last_id而非页码，后端用WHERE id
移动端 Feed 流用瀑布流（WaterFlow）+ 分页是常见但危险的组合——它表面合理，实际容易触发重复加载、漏数据、卡顿三连问题。GORM 本身不支持游标分页，硬套
Limit/Offset在 Feed 场景下会随滚动深度指数级变慢，必须换思路。为什么不能直接用 GORM 的 Limit/Offset 做瀑布流分页
瀑布流本质是“无限滚动”，用户滑到底部就加载下一批，但
Offset((page-1)*pageSize)每次都要跳过前面所有记录。当用户已刷到第 50 页（每页 20 条），Offset(980)在 MySQL 上需扫描并丢弃前 980 行，响应时间从 20ms 拉到 1.2s+，且越往后越卡。
- Feed 数据天然按时间倒序，但高并发下
created_at可能重复（毫秒精度），仅靠它排序会导致同一页出现漏或重Count(*)查询在 Feed 场景中毫无意义：用户不需要知道“总共多少条”，只需要“还能不能往下拉”- 前端瀑布流组件（如 ArkUI 的
WaterFlow）依赖“是否还有下一页”信号，而len(results) 这种判断在有删除/状态过滤时不可靠用 created_at + id 组合游标替代 Offset
放弃页码概念，改用“最后一条数据的
created_at和id”作为下一页起点。这是唯一能避免OFFSET性能坍塌的方式，且 GORM 完全支持。
- 查询条件必须写成：
WHERE created_at- 第一次请求不带游标，取最新 20 条；后续请求带上上一页最后一条的
created_at和id- GORM 写法示例：
db.Where("created_at- 注意：字段类型要匹配，
created_at用time.Time，id用主键类型（通常是int64），别传字符串如何安全地把游标透传给前端并防篡改
游标值（
created_at+id）不能明文暴露给前端拼接 URL，否则用户可手动修改造成越权或错乱。
- 后端生成一个短时效、带签名的游标 token，例如：
base64(urlencode({at: "2026-08-20T14:22:10Z", id: 12345})) + "." + hmac.Sign(...)- 前端只传这个 token，后端校验签名和有效期（建议 ≤ 10 分钟），再解出原始游标值
- 别用 JWT：太重；也别用纯 base64：无防伪；简单 HMAC-SHA256 足够
- 如果业务允许弱一致性，可省略签名，但至少做
created_at范围校验（如不允许早于 7 天前）Feed 流中 GORM Preload 关联数据的陷阱
瀑布流每条 Feed 可能需展示作者头像、点赞数、评论数等，但直接
Preload("Author")或Preload("Likes")会引发 N+1 或爆炸式查询。
Preload("Author")是安全的，它转成 JOIN 或 IN 查询，但要注意：若作者被软删除，关联结果为空，需手动补默认值Preload("Comments")危险——它会查出全部评论，不是“最新 3 条”。应改用子查询或额外 SQL：SELECT ..., (SELECT COUNT(*) FROM comments WHERE blog_id = blogs.id) AS comment_count- 更推荐方式：主查询只查 blog 列表，用一次
IN批量查作者信息，再用一次IN批量查各 blog 的点赞数/评论数，避免嵌套- GORM v2 中
Preload默认不支持 limit，强行加Limit(3)会作用在整个预加载语句上，而非每个 blog真正难的不是写对第一条游标查询，而是让所有关联字段的加载、软删除过滤、状态校验、缓存穿透控制都在同一事务边界内保持一致——这些细节一旦漏掉，瀑布流就会在某个凌晨三点开始随机丢数据。
基于GORM框架的移动端Feed流瀑布流分页设计
夏丽小哥_2697
2026-11-15
281人浏览
原创
