北京
社区类产品看起来像是普通的CRUD应用，实际跑起来却像是一个"有情绪的分布式系统"。这是很多开发者踩坑后才明白的道理——包括那些已经在这个领域摸爬滚打多年的工程师。
一位长期从事社区与社交功能开发的工程师，结合自身经验，总结出了社区平台开发中最容易出错、也最关键的三个工程决策。这篇文章没有推销任何框架，也没有高深的产品哲学，只有实打实的代码层面判断。
决策一：信息流不是查询，第一天就要定好扇出策略
几乎每个社区平台都有信息流，而几乎所有新手实现都从同一条SQL语句开始：从关注表中找出用户关注的人，拉取他们的帖子，按时间排序，限制20条。
这条查询在demo演示时毫无问题，在1000个用户时也能接受。但当你的平台头部成员拥有5万粉丝、关注表达到数千万行时，这条查询就会成为运维团队的噩梦。
真正的决策点在于：写入时扇出，还是读取时扇出。
- 写入时扇出：用户发帖时，把帖子ID推送到每个关注者的预计算信息流中，读取是O(1)级别的即时操作。代价是热门账号的写入成本爆炸——一个10万粉丝的成员发一条帖子，意味着10万次列表插入。
- 读取时扇出：请求时实时计算信息流，配合重度缓存。写入成本低，但读取成本会越来越高。
- 混合方案（多数平台最终的选择）：普通账号用写入时扇出，粉丝量超过阈值的"名人账号"用读取时扇出，读取时合并结果。
作者给出的建议是：上线第一天不需要混合方案，但代码结构必须把信息流生成放在一个独立接口后面，这样后续切换策略只是换实现，而不是重写整个系统。如果一开始就让六个功能直接查询posts表，等要改造时，等于重写一遍。
决策二：信任等级是最便宜的审核系统
作者分享了自己做过的一个性价比最高的审核功能，它不包含任何机器学习，但效果惊人：基于账号注册时长和参与度的分级权限体系。
这套体系分为五级：新用户只能阅读和表态，不能发链接、发图片或发送站内消息；基础用户可发帖评论但有频率限制，链接需审核；正式成员拥有正常发帖、图片和站内消息权限；老用户可创建话题和空间，举报权重提高；资深用户可编辑标题、移动帖子和处理审核队列。
垃圾机器人不会为了发帖权限投入三周的真实参与，这种分级体系在它们接触举报队列或毒性分类器之前，就从结构上把它们过滤掉了。这也是Discourse能靠这套模式运行十年的原因。
作者特别提醒了一个从实战中总结的教训：信任等级计算务必用异步任务，比如夜间定时任务，绝不能在请求链路中同步计算。
为什么这些决策如此重要？
社区平台的本质是：它看起来像一个普通的增删改查应用，但用户的每个操作都在产生社交关系、内容分发和实时互动。这些特性决定了它天生就是一个分布式系统。用做CRUD应用的思路去做社区平台，初期一切顺利，等真实用户涌入，问题才会集中爆发。
好在这些问题都有成熟的解决路径。关键在于，别等到系统已经被真实用户压垮时，才开始思考这些本来应该在写第一行业务代码之前就想清楚的问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
