事件驱动架构实践：校园论坛消息通知功能的实现过程

校园论坛长期缺乏互动提醒功能，导致用户错过重要反馈。本文详解如何通过事件驱动设计实现消息通知系统，让社区互动形成闭环。 前言 我的校园论坛已经有了帖子发布、评论互动、嵌套回复、评论点赞等功能。但一直缺少一个关键环节：用户之间互动了，对方却不知道。 有人回复了你的帖子，你不知道。有人赞了你的评论，你也不知道。这导致社区感很弱——用户发了帖子就再也不会回来看了。 消息通知就是解决这个问题的最后一块拼图。做完之后，用户之间的互动就形成了闭环。 一、设计思路：事件驱动，而非用户主动发送 我最开始把消息通知想复杂了——以为需要做一个“私信”系统，用户主动给对方发消息。后来想通了：通知不是用户“写”出来的，而是由用户的互动行为自动产生的副产品。 具体来说： 有人评论了你的帖子 → 系统自动通知你 有人回复了你的评论 → 系统自动通知你 有人赞了你的帖子 → 系统自动通知你 有人赞了你的评论 → 系统自动通知你 这个设计思路的核心是：不修改核心业务逻辑，而是在现有的动作上附加一个副作用。 这和之前做过的“统一在出口处做匿名处理”是同一个思维模式。 二、数据模型：一张表记录所有通知 const notificationSchema = new mongoose.Schema({ type: { type: String, enum: ['comment', 'reply', 'like_post', 'like_comment'], required: true }, sender: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true }, receiver: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true }, postId: { type: mongoose.Schema.Types.ObjectId, ref: 'Post', required: true }, commentId: { type: mongoose.Schema.Types.ObjectId, default: null }, isRead: { type: Boolean, default: false } }, { timestamps: true }) 四个字段决定了每条通知的完整信息： type：通知类型，四种枚举值 sender：谁触发的通知 receiver：谁收到通知 postId：关联的帖子，点击通知后跳转用 commentId：关联的评论（可选） isRead：是否已读 三、后端实现：在现有接口里“顺便”写入通知 这是整个功能最核心的设计决策。我没有新建专门的通知发送接口，而是在现有的评论和点赞接口里，执行完核心操作后多写一行代码。 改造评论接口： // 评论帖子 → 通知帖子作者 if (post.author.toString() !== req.user._id) { await Notification.create({ type: 'comment', sender: req.user._id, receiver: post.author, postId: postId }) }// 回复评论 → 通知被回复者 if (replyTo && 被回复的评论作者 !== 自己) { await Notification.create({ type: 'reply', sender: req.user._id, receiver: 被回复的评论作者, postId: postId, commentId: replyToCommentId }) } 改造点赞接口（帖子点赞和评论点赞同理）： if (被点赞的对象的作者 !== 点赞者) {