MERN栈SNS应用开发：MongoDB统计用户回复总点赞数的实现与Schema优化

不新增任何字段的前提下，完全可以通过MongoDB原生聚合能力实现总点赞数统计，核心逻辑是基于Reply的likes数组长度计算单条回复点赞量，再按作者分组累加。

• 单用户总点赞数查询代码：

// 入参targetUserId为需要统计的用户ObjectId
const userLikeStats = await Reply.aggregate([
  // 匹配目标用户发布的所有回复
  { $match: { author: targetUserId } },
  // 计算每条回复的点赞数：取likes数组的元素长度
  { $addFields: { singleLikeCount: { $size: "$likes" } } },
  // 按作者分组累加总点赞
  { $group: {
      _id: "$author",
      totalLikes: { $sum: "$singleLikeCount" }
    } 
  }
])

• 全平台用户排行榜查询代码：

const likeLeaderboard = await Reply.aggregate([
  { $addFields: { singleLikeCount: { $size: "$likes" } } },
  // 按作者维度聚合所有回复的点赞数
  { $group: {
      _id: "$author",
      totalLikes: { $sum: "$singleLikeCount" }
    } 
  },
  // 关联User集合拉取用户公开信息
  { $lookup: {
      from: "users",
      localField: "_id",
      foreignField: "_id",
      as: "profile"
    } 
  },
  { $unwind: "$profile" },
  // 按总点赞数从高到低排序
  { $sort: { totalLikes: -1 } }
])

虽然可以实现统计逻辑，但当前设计存在多处影响长期性能和使用体验的问题：

• 主帖（Post）维度缺少点赞能力，不符合常规SNS的交互逻辑，只能对回复点赞
• Reply的post字段为数组结构，单条回复可关联多个帖子，极易产生脏数据，后续关联查询的逻辑复杂度会成倍上升
• 高点赞场景下，likes数组的性能瓶颈明显：单条内容点赞量破万后，文档体积会快速膨胀，每次点赞/取消点赞都需要读写整个大数组，更新耗时会显著上涨
• 排行榜查询无冗余字段支撑，每次都需要全量扫描Reply集合做聚合，数据量达到十万级后，查询延迟会成为明显的性能问题

在不改变核心交互逻辑的前提下，可从结构合理性和性能角度做如下调整：

• 修正Reply的关联结构：将post: [{ type: Schema.Types.ObjectId, ref: 'Post'}]修改为单值关联post: { type: Schema.Types.ObjectId, ref: 'Post' }，保证单条回复只归属单个帖子
• 给Post Schema增加同款likes: [{ type: Schema.Types.ObjectId, ref: "User" }]字段，支持主帖点赞交互
• 在User Schema中增加冗余统计字段totalReceivedLikes: { type: Number, default: 0 }：当点赞/取消点赞操作触发时，同步对该字段做增量更新（点赞+1、取消点赞-1），后续查询排行榜时直接按该字段排序，无需重复执行全量聚合，查询性能可提升数倍

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