核心矛盾是「发布扇出」：读多还是写多决定推（写扩散）拉（读扩散）选型。推模式——发帖时把内容 ID 写入所有粉丝的收件箱（Feed 表），读取时直接查自己的收件箱，读快写重：大 V 发帖产生千万级写放大。拉模式——读取时实时聚合所有关注对象的新帖，写快读重：每次刷新都要 N 次查询 + 归并排序。生产系统是推拉结合：普通用户走推（粉丝少写放大可控）、大 V 走拉（发帖不扇出，读者刷新时临时拉取大 V 内容合并）、活跃用户优先推（僵尸粉不推省存储）。
其他设计点：1）收件箱存储——每用户一个按时间排序的列表（Redis ZSet 存 ID + 分数时间戳，DB/NoSQL 持久化），只保留最近 N 条截断；2）分页用 cursor（上一页最后一条的时间戳/ID）而非 offset（新内容插入会导致翻页错位重复）；3）内容本体与索引分离，收件箱只存 ID，读取时批量回表，配多级缓存；4）异步化——扇出写进 MQ 消费者慢慢推，发帖接口只写发件箱立即返回；5）排名信息流（非纯时间序）引入特征拉取 + 粗排精排模型，是推荐系统的范畴。追问方向：删除/编辑帖子如何在已扇出的收件箱中处理（软删除标记 + 读取时过滤）、实时性要求下的长连接推送、热点大 V 突发发帖的削峰。
（约 490 字）