自今年开始，本人一直在进行微信小程序“青笺集-Azure Chronicle”的开发工作。目前该项目已基本完工，并正式进入长期维护阶段。趁着功能迭代暂告一段落，我终于有时间重新审视这次开发过程中的不足与弯路，希望能给未来的自己敲个警钟。 本人能力有限，本文主要聚焦于小程序的核心代码逻辑整理与架构演进，如果有更优雅的解决方案，还请各位前辈指正。
1. 用户生成内容（UGC）需求分析及解决方案
所有社交类APP最先要解决的东西就是用户生成内容（UGC）的管控。出于本小程序是校园社交分支，存在用户量相对不大，信息的时效性需求不高，产生信息的密度也会远低于其他类型的社交类APP的特点。最终采用的解决方案是：机器关键词监测+人工复审。
第一步：所有用户生成内容一概接入微信提供的内容安全API（文字+图片+视频）
第二步：API返回通过语句时，再次转交给有管理员权限的用户进行二次复审。管理员确认通过后，内容才会进入公开显示状态。
如果内容安全API未通过，会立马从数据库删除相关内容，避免监察巡查数据库时发现违禁内容。如果人工审核未通过，管理员需要说明未通过原因后打回给发布者，让发布者修改相关内容后再次提交。
2. 首页内容展示需求分析及解决方案
千篇一律的论坛APP已经足够多了，市场不缺我这一个。个人十分排斥如今各类APP中极其臃肿的附加功能——每个应用各司其职，干好本职工作就足够了。
我期望“青笺集”能成为一个增加学生群体凝聚力、降低年级与班级间沟通门槛的纯净平台。然而，指望每个学生都在墙上高频发布动态并不现实，许多人在表达时会存在“社交恐惧”。人类天生在寻求群体认同感，不敢去当出头鸟。所以我们调整了交互比重，大幅加重了“评论”的权重：
设立“神评”窗口：在首页直接露出神评，让优质的观点成为社区的门面。
引入“每日话题”机制：板块内包含红蓝对抗、传统投票和自由讨论。每天抛出一个争议点，让用户能直观看到有多少人与自己想法契合，从而降低发言门槛，激发讨论欲。
同时，基础的论坛闭环功能（评论、收藏、举报）被保留并做到了极简。
3. 首页交互痛点分析：缓存策略与高频互动的无感重构
index首页作为小程序的门面，每天所有用户在这个页面的跳转次数是最多的。既要展示每天更新的“每日话题”，又要承载大家不断发布的动态。在开发初期，我总结出了两个痛点：
一是服务器压力：如果用户每次打开首页，都去数据库把话题和动态全量拉取一遍，不仅会导致首屏加载慢，数据库读取配额也根本扛不住。
二是互动卡顿问题：用户在信息流里点赞或收藏，如果按照老一套的逻辑（发请求给服务器 -> 等待服务器处理成功 -> 重新拉取列表刷新UI），就算在现在网络环境十分出色的当下，也一样在点赞是感觉到延迟。甚至在弱网环境下会有明显卡顿。
为了兼顾体验和成本，我在这两个方面对底层逻辑进行了彻底的重构。
（1）数据加载策略：动静分离与长效缓存
既然不能每次都去服务器要数据，那就必须把数据拆开来看。我把首页数据分为了“静态数据”和“动态数据”：
静态数据： 像“每日话题”这种板块，固定是每天早上 7 点才换题。对于这种数据，前端会在用户第一次加载时，算出一个“距离当前最近的早7点”的时间戳，并把整个话题数据塞进手机本地缓存里。只要时间没跨过早7点，无论用户打开多少次小程序，程序都会直接从本地内存里把话题秒读出来。这不仅做到了零延迟，还顺便减少了服务器开支。
动态数据： 话题可以存本地，但话题下面的“神评”是实时计算出来的。在加载完本地的话题后，我会让程序单独向数据库发一次极小的轻量级查询，专门只拉取当前点赞最高的那条评论。用最少的流量，保证了社区的核心互动感。
（2）互动交互逻辑：局部状态的“所见即所得”
在处理点赞、收藏和评论这三个最高频的操作时，我放弃了传统的“等服务器响应再刷新”的做法，全面改用了“先渲染，后同步（乐观更新）”的逻辑。
点赞与收藏的毫秒级反馈： 当用户点击列表里某条动态的点赞或收藏按钮时，前端不再傻等后端返回结果。我会立刻抓取这个帖子在数组里的具体位置（Index），直接用 setData 把那个心形图标点亮，并让点赞数 +1。与此同时，把真正的点赞请求悄悄丢给后台去处理。对于用户来说，点下去的瞬间就看到了视觉反馈，操作做到了真正的丝滑流畅。
评论的无缝上屏： 评论功能也是一样的思路。由于引入了微信的内容安全审核API，审核+存库是需要时间的。为了不让用户觉得“发不出去”，只要用户点击发送并且通过了本地格式校验，程序会立刻在前端凭空“捏”一条带有他头像和名字的评论，强行插到当前评论列表的最顶端。等视觉上已经发送成功了，后端再去默默完成真正的安全审核和数据库入库逻辑。
不管是做缓存还是做局部刷新，核心目的只有一个：把需要等待的操作全部异步留给后台，把流畅的体验留给用户。
4. 首页动态推荐刷新逻辑
首页不仅需要展示每日更新的话题，还要承载用户实时发布的动态信息流。如果每次下拉刷新都向服务器请求全量数据，会导致网络流量平白无故的被消耗殆尽，网络延迟也会使用户终端每次刷新都有卡滞感觉。基于校园墙动态信息密度较低，每次刷新10条动态可能有8条都是重复的，我设计出了一种基于“时间游标（Cursor）”的增量拉取逻辑。
以下是在执行下拉刷新时的代码流程逻辑：
(1)把本地动态的最新时间发向后端
(2)后端根据该最新时间进行匹配查询
（2-1）如果没有比本地更新的动态，后端返回空数组。前端收到后结束加载，本地动态数据保持原样，不作改动。
（2-2）如果有比本地更新的动态，后端返回这些新动态数据。
（2-3）前端拿到新数据后进行去重校验：提取当前本地列表中所有动态的ID，过滤掉新数据中重复的部分。
（2-4）将去重后的新动态数据，直接拼接到本地动态列表的最上方，优先显示。
以下是进行上拉触底（加载更多）时的代码流程逻辑：
(1)把本地动态的最早时间发向后端
(2)后端根据该最早时间进行匹配查询
（2-1）如果没有比本地更早的动态，后端返回空数组。前端收到后结束加载，并标记不再发起请求。
（2-2）如果有比本地更早的动态，后端返回这批历史动态数据（限制10条）。
（2-3）前端拿到历史数据后进行去重校验：提取当前本地列表中所有动态的ID，过滤掉已经被加载过的动态。
（2-4）将去重后的历史动态数据，追加拼接到本地动态列表的最下方。
更多功能体验欢迎搜索访问微信小程序：青笺校园日记
