从发布框到点赞按钮：信息流交互的状态设计课

打开任何一个内容类产品，最先看到的几乎都是同一种界面：一列卡片往下排，顶部一个发布框，每张卡片下面跟着点赞、评论、分享。把这套界面跑起来不难，照着组件库文档半天就能拼出原型；真正的功夫藏在交互层的状态设计里——发布框怎么接进列表、点赞数怎么改才不会"改了个寂寞"、占位的按钮怎么一步步变成真功能。本文按一次实际的实现顺序，把这条交互链路完整拆开。

一、骨架：卡片列表加一个表单

技术栈用 React，组件库选 shadcn/ui：Card、CardHeader、CardContent 拼卡片，Input 和 Button 拼表单，图标用 Lucide。这类"代码直接复制进自己仓库"的组件库，特别适合信息流这种要反复定制的界面——没有黑盒，想改哪一行就改哪一行。相比之下，MUI、Ant Design 这类打包好的传统组件库开箱即用、主题系统成熟，代价是定制要沿着库预留的口子走，样式想突破得跟它的默认风格较劲。原型阶段图快用哪个都行，但信息流这种每个产品都长不一样的界面，长期看"源码在手"的方案更省心。

动手前先定数据形状。整个界面只有两块状态，各管一摊：

jsx

const [posts, setPosts] = useState([
  { id: 1, title: '...', content: '...', likes: 10 },
]);
const [newPost, setNewPost] = useState({ title: '', content: '' });

posts 是列表数据，newPost 是正在编辑的草稿。草稿单独建成状态，而不是绕过 React 直接去读输入框，这就是受控组件模式——输入框的值永远由状态驱动，状态是唯一的事实来源。它的好处是校验、联动、清空全都顺着状态来：标题超长就禁用发布按钮、草稿自动存草稿箱，都只是在状态上做文章。反过来，非受控组件（defaultValue 加 ref 取值）省掉了每次按键的重渲染，单字段大表单有性能顾虑时才值得考虑；发布框这种两三个字段的小表单，受控写法的心智负担最低。

发布与点赞的状态流转

二、发布框：受控组件两件套

发布逻辑集中在表单的 onSubmit 里：

jsx

const handleSubmit = (e) => {
  e.preventDefault();
  if (!newPost.title || !newPost.content) return;
  setPosts([{ id: posts.length + 1, ...newPost, likes: 0 }, ...posts]);
  setNewPost({ title: '', content: '' });
};

几行代码里有三个值得说透的细节。

新帖插在头部。 信息流的心智模型是"最新的在最上面"，这也是几乎所有社交产品的默认排序。展开运算符 [draft, ...posts] 生成一个新数组，而不是用 unshift 直接改原数组——后者在 React 里属于典型的状态突变，后果下一节细说。

提交后清空草稿。 清空 newPost 和插入新帖是同一次事件里的两次 setState，React 会自动批量处理，界面一次性刷新，不会出现"帖子出来了、输入框还留着字"的中间态。

id 别用数组长度凑。 posts.length + 1 在 Demo 里能跑，但它是颗地雷：一旦支持删除，删掉中间某条再发新帖，id 就会与现存帖子撞车。id 是列表 key 的身份证明，key 撞了，React 的协调算法会把 A 帖的状态安到 B 帖头上，表现为输入框串内容、点赞数错位这类灵异现象。用一个 useRef 存自增计数器，或者直接 crypto.randomUUID()，都比数组长度可靠。

三、点赞：不可变更新是铁律

点赞按钮的处理函数只有一层 map：

jsx

const handleLike = (id) => {
  setPosts(posts.map(post =>
    post.id === id ? { ...post, likes: post.likes + 1 } : post
  ));
};

初学者最常见的疑问：为什么不直接 post.likes++？因为 React 判断状态"变没变"，看的是引用是不是同一个对象。直接改属性，引用没变，塞回 setPosts 的还是原来那个数组，React 认为无事发生，界面纹丝不动——改动就这么无声地丢了。map 加展开运算符的写法，每次都交出新数组、命中的那条交出新对象，引用变了，重渲染才会发生。反过来要留神一件事：没被点赞的帖子拿到的是原对象引用，如果卡片组件包了 React.memo，它们会自动跳过重渲染——这正是 memo 与不可变更新配合的默契所在；一旦哪次图省事原地改了对象，memo 的浅比较就被骗过去，界面和数据从此对不上账。

接上真实后端之后，点赞还差一步：乐观更新。如果等服务器返回 200 再把数字加一，弱网下按钮会有肉眼可见的迟钝。通行做法是先改本地状态让界面立即响应，再异步发请求，失败时把状态滚回去。一小段代码，换来的是交互手感质的提升，属于信息流的必修课。

从 MVP 到完整交互层的升级清单

四、把评论和分享接上

原型里评论和分享只是两个占位按钮，接上它们正好覆盖剩下的两类交互。

评论是嵌套数据。 数据形状上给每条帖子挂一个 comments 数组；"展开还是收起"这种纯界面状态，放在卡片组件自己的 useState 里就够了，不必进全局。评论正文要持久化就得走后端接口——届时更新函数会明显变啰嗦，两层嵌套的不可变更新写起来相当费劲，这正是抽出一个 reducer、或者把数据交给请求库托管缓存的时机。

分享是浏览器原生能力的天下。 支持 Web Share API 的环境直接调 navigator.share() 拉起系统分享面板；不支持的降级为 clipboard.writeText() 复制链接。十几行代码，占位按钮就变成了真功能。

至于用户认证，它决定的不是界面长相而是数据权限：谁能发、能赞谁的、能不能删。发布框接上 API 之后，草稿状态和非空校验原样保留，变的只是数据来源从本地数组换成了接口。

五、再加一层：实时同步

单人 Demo 不会遇到这个问题，一旦多人同时用，"别人发了新帖我怎么知道"就冒出来了。三种方案按实现成本从低到高：

轮询：定时拉一次接口，实现最简单，延迟和服务器压力都随频率上涨；
SSE：服务器单向推送，浏览器原生 EventSource 支持，信息流这种"只需要被告知"的场景完全够用；
WebSocket：双向通道，聊天室、协作编辑才需要付出的复杂度。

选型时还要把"连接会断"当默认前提：无论 SSE 还是 WebSocket 都要做断线重连和心跳保活，重连风暴来临时降级成轮询兜底，是这类长连接方案的标配容错动作。

还有个容易忽略的产品细节：收到"有新帖"的通知后别急着往列表顶部插——用户正滚到一半，突然的插入会把阅读位置顶跑。常见做法是先显示一条"有 N 条新内容，点击查看"，由用户决定何时跳转。

写在最后

信息流的交互层拆开看就是四件事：受控表单管输入，不可变更新管修改，稳定 id 管身份，实时方案管同步。发布和点赞是其中最小又最典型的两个，把它们的模式吃透，评论、分享、认证都只是同一套原则在不同数据形状上的重复应用。下次从空白文件开始写信息流时，不妨按这个顺序推进：先跑通发布框和点赞，再补 id 的健壮性，然后逐个接上评论、分享与实时——每一层踩实了，Demo 到产品之间的路，没有想象中那么长。