应采用基于主键或时间戳的游标分页，避免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 完全支持。

GORM框架 1.30.3

GORM框架 1.30.3版本源码包下载，版本号 1.30.3，适合在 1.30 主线早期节点做源码留档、依赖回放和升级前后行为对照。

下载

• 查询条件必须写成：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

真正难的不是写对第一条游标查询，而是让所有关联字段的加载、软删除过滤、状态校验、缓存穿透控制都在同一事务边界内保持一致——这些细节一旦漏掉，瀑布流就会在某个凌晨三点开始随机丢数据。