在解决了基础的内容准入（UGC审核）与首页加载策略后，“青笺集”进入了互动功能的密集开发期。点赞、评论与收藏，这三个动作看似简单，但在实际的校园网络环境与云开发架构下，如何保证体验的“丝滑”与数据的“精准”，其实藏着不少细节。

本篇日志将聚焦于互动模块背后的逻辑演进，分享我在处理状态同步、计数性能与消息触达时的一些实战总结。

1.跨页面状态同步

在之前的开发中，我发现了一个典型的交互痛点：用户在“首页”点亮了某条动态，进入“详情页”后，星星却又是熄灭的。这种“状态不同步”往往源于参数传递不严密或旧数据的干扰。

为了实现零延迟、零消耗且绝对一致的状态同步，我重构了“详情页”与“首页”的通信逻辑：

后端净化（MatchCond）： 彻底抛弃早期模糊的匹配条件，在云函数端建立极其纯净的“精准匹配”。强制校验用户的唯一身份 ID，查不到就是没点，从源头掐断干扰。
前端路由栈反向注水： 我放弃了触发全局事件这种较重的方案，转而利用小程序 getCurrentPages() 获取页面栈。在详情页操作成功后，直接定位到上一级首页实例，利用 setData 的局部路径更新特性，精准修改首页对应的数组项。

相关代码

// 详情页同步逻辑：直接操作页面栈实现零延迟
syncToHomePage(field: string, val: any) {
const pages = getCurrentPages();
if (pages.length > 1) {
const prevPage = pages[pages.length – 2];
if (prevPage.route.includes(‘index/index’) && prevPage.data?.posts) {
const index = prevPage.data.posts.findIndex(p => p._id === this.data.post._id);
if (index !== -1) {
// 精准更新，避免全量刷新列表
prevPage.setData({ [`posts[${index}].${field}`]: val });
}
}
}
}

2. 轻量化数字统计

如果每次展示动态都要通过 count() 来实时计算点赞数，对于云开发配额和数据库压力来说都是不可接受的。因此，我采用了反范式设计（Denormalization）。

冗余计数与 _.inc： 在帖子主表中冗余存储 likeCount 等字段。当发生互动时，云函数只负责执行增量操作。利用原子操作符 _.inc()，我们在写入点赞明细的同时，对主表计数进行自增。
热度分机制： 在更新计数的同时，同步引入 hotScore 计算逻辑（例如：点赞增加 30 分钟热度权重，收藏增加 120 分钟）。这种原子级的同步更新，确保了排序权重与互动动作的实时绑定，无需额外的定时脚本处理。

3. 互动信箱的事件分发逻辑

为了让社区具备更强的反馈感，互动动作必须触发信箱提醒。但“发送通知”不应阻塞“点赞成功”的主逻辑。

我采用了 Promise 任务收集机制 实现了业务解耦：

异步并发处理： 在处理互动的云函数中，将主业务（写入点赞、更新计数）与附属业务（信箱推送、经验结算）拆分。利用 Promise.all 并发执行。
信箱摘要设计： 信箱系统并不存储全量数据，而是存储轻量化的摘要（Snippet）。例如“张三赞了你的动态「今天天气真好…」”。

信箱具体功能逻辑将再之后详细分析…

相关代码

// 云函数端任务编排
const tasks = [];
tasks.push(db.collection(‘timeline_posts’).doc(postId).update({ … })); // 主业务
if (!isSelfAction) {
// 异步推送通知，不影响主业务
tasks.push(mailUtils.sendLikeNotification({ … }));
tasks.push(xpUtils.addXp({ … })); // 接入经验值相关功能
}

await Promise.all(tasks);

回顾社交互动功能的开发，我最大的体悟是：好的体验往往建立在极其严苛的数据规范之上。 构建一个系统就像搭建齿轮。前端的乐观渲染是表盘，路由通信是传动轴，后端的并发推送是底层的发条。只有它们严丝合缝地互相咬合，才能在有限的资源下，呈现出最终顺滑的社区互动体验。

写代码也是一场修行，希望这些踩坑记录能为未来的自己敲个警钟。

更多功能体验欢迎搜索访问微信小程序：青笺校园日记