NestJS中使用GraphQL实现关注用户商品Feed查询

结合你使用MongoDB、现有实体关联的设计，按业务规模分两种可直接落地的实现方式，避开常见的性能坑：

方案1：小数据量快速上线版 #

适合总用户量万级以下、单用户关注数不超过200的早期场景，不需要修改现有数据结构，10分钟就能写完上线：

• 核心逻辑：不要循环遍历每个关注用户拉取商品再手动拼接，直接在商品表做匹配查询，避免N+1问题和内存排序开销
• Resolver参考实现：

// GraphQL resolver 示例
async function feedResolver(parent, { offset = 0, limit = 20 }, context) {
  // 从登录上下文拿到当前用户，拉取已关注的用户ID列表
  const currentUser = await User.findById(context.currentUser.id).lean()
  const followingIds = currentUser.following || []
  // 空关注列表直接返回空数组，避免无效查询
  if (followingIds.length === 0) return []
  // 直接匹配商品作者在关注列表内的结果，按发布时间倒序
  return Product.find({ author: { $in: followingIds } })
    .sort({ createdAt: -1 })
    .skip(offset)
    .limit(limit)
    .populate('author', 'username avatar') // 只填充需要展示的用户字段，不要拉全量用户数据
}

• 对应GraphQL Schema定义：

type Query {
  # 支持分页参数，默认每页20条
  feed(offset: Int = 0, limit: Int = 20): [Product!]!
}

• 注意点：这个方案实现成本最低，但必须给Product表的author和createdAt字段加索引，否则数据量上来之后查询会非常慢。

方案2：中大规模流量优化版 #

适合用户量十万级以上、单用户关注数过千的生产场景，从数据结构到查询逻辑做全链路优化：

• 第一，砍掉冗余关联：不要在User表维护listing数组存商品ID，发商品、删商品的时候双写两个集合非常容易出现数据不一致，商品归属关系完全靠Product表的author字段维护即可，减少维护成本
• 第二，解决GraphQL N+1问题：不要用默认populate拉取关联作者信息，引入DataLoader做批量查询，同一次Feed请求里需要的作者信息统一拉取，把N次数据库请求合并成1次
• 第三，深分页优化：把offset+limit的分页改成游标分页，避免大skip带来的性能损耗，查询时拿上一页最后一条商品的_id和createdAt作为游标，走索引匹配即可
• 第四，超大规模场景改用推模式Feed：单独建feed_inbox集合，存储结构为{ fanUserId: ObjectId, productId: ObjectId, createdAt: Date }，给fanUserId + createdAt建联合索引。用户发布新商品时，异步把商品ID推送到所有粉丝的收件箱；查询Feed时直接查当前用户对应的收件箱记录，查询性能不随总数据量上涨波动，适合百万级以上用户的场景。

避坑提醒 #

• 绝对不要写循环遍历关注列表、逐个拉取用户商品再内存拼接排序的逻辑：关注数稍大就会产生大量数据库请求，内存排序分页很容易触发服务OOM
• populate不要拉取关联表的全量字段，只 select 前端需要展示的字段，减少内存开销和数据传输量
• 所有关联查询的字段必须建索引，MongoDB的$in查询在有索引的场景下性能完全能支撑中小规模业务

内容的提问来源于stack exchange，提问作者Jose Zamudio