在解决了基础的内容准入（UGC审核）与首页加载策略后，“青笺集”进入了互动功能的密集开发期。点赞、评论与收藏，这三个动作看似简单，但在实际的校园网络环境与云开发架构下，如何保证体验的“丝滑”与数据的“精准”，其实藏着不少细节。
本篇日志将聚焦于互动模块背后的逻辑演进，分享我在处理状态同步、计数性能与消息触达时的一些实战总结。
在之前的开发中，我发现了一个典型的交互痛点：用户在“首页”点亮了某条动态，进入“详情页”后，星星却又是熄灭的。这种“状态不同步”往往源于参数传递不严密或旧数据的干扰。
为了实现零延迟、零消耗且绝对一致的状态同步，我重构了“详情页”与“首页”的通信逻辑：
- 后端净化（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 });
}
}
}
}
如果每次展示动态都要通过 count() 来实时计算点赞数，对于云开发配额和数据库压力来说都是不可接受的。因此，我采用了反范式设计（Denormalization）。
-
冗余计数与 _.inc： 在帖子主表中冗余存储 likeCount 等字段。当发生互动时，云函数只负责执行增量操作。利用原子操作符 _.inc()，我们在写入点赞明细的同时，对主表计数进行自增。
-
热度分机制： 在更新计数的同时，同步引入 hotScore 计算逻辑（例如：点赞增加 30 分钟热度权重，收藏增加 120 分钟）。这种原子级的同步更新，确保了排序权重与互动动作的实时绑定，无需额外的定时脚本处理。
为了让社区具备更强的反馈感，互动动作必须触发信箱提醒。但“发送通知”不应阻塞“点赞成功”的主逻辑。
我采用了 Promise 任务收集机制 实现了业务解耦：
信箱具体功能逻辑将再之后详细分析…
相关代码
// 云函数端任务编排
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);
