27 篇博文 含有标签「React」

这次优化很小，但非常值钱。问题出在一个对话页：模型流式返回 token 时，我们最初每收到一段就直接 setState 一次，结果页面在长回答场景里会明显抖动，尤其是移动端更明显。

最初大家直觉上以为这是“模型流太慢”或者“前端机器太差”，但真正看性能面板后才发现，问题不是响应慢，而是我们把过多的小更新直接推给了 React 渲染。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-04-28 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

如果只拿一个具体页面来说这个问题，我会选“运营助手”里的改写面板。

这个面板的交互表面很普通：用户贴一段原始文案，点“优化”，系统开始生成一版可发布草稿。我们最早做的时候，认为流式输出只是锦上添花，于是做了一个很自然的版本：后端流式返回 token，前端就把 token 不断 append 到页面里。能跑，效果也看起来很“AI”。

但上线一周后，反馈几乎都集中在体验而不是效果上：

• “它到底是还没生成完，还是卡住了？”
• “我想复制刚才那句，结果它还在跳。”
• “中间突然停了三秒，我以为挂了。”
• “我点了继续生成，怎么前面那段也被改了？”

这时候我才真正意识到：对话产品前端里，流式输出不是一个展示细节，而是一整套状态管理问题。模型决定内容质量，前端决定用户是否愿意把这个过程当成一个可靠工具来使用。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-04-10 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

React 19 正式落地之后，前端圈很自然会讨论“它到底带来了什么变化”。但如果把场景缩小到 AI 产品，我更关心的不是版本号本身，而是哪些能力真的能改善 AI 交互中的真实问题。因为 AI 产品前端和普通内容站点不太一样，它天然会面对几类更极端的状态：

• 响应慢
• 状态切换频繁
• 流式结果不断变化
• 表单和生成链路交织
• 用户经常要在“等待”“修改”“继续执行”之间来回切换

在这种场景里，前端体验的核心不是“页面够不够炫”，而是“用户会不会在等待和变化中失去控制感”。从这个角度看，React 19 真正有价值的能力，并不是平均意义上的升级项，而是那些能让状态过渡更顺、交互反馈更稳、异步处理更自然的能力。

缓存失效策略 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 改了一条数据后不知道该刷新哪个层级，最后只能一股脑全刷，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。

2023 年的前端生态里，Next.js App Router 是一个非常有代表性的变化。它吸引人的地方，不只是目录结构变了，而是 React 应用开始更明确地向“服务端优先”靠近。

Server Actions 表单变更 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 提交逻辑看起来更简洁了，但错误反馈和 pending 状态反而散掉了，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。

loading/error 边界 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 每个子路由都各自弹 loading，用户只会觉得页面一直在闪，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。

Next.js 13 在 2022 年带来的讨论点很多，但真正让人记住的，还是 App Router 这条新路。它代表的并不只是目录变化，而是 React 应用组织方式在慢慢变化。

Next.js 13 刚出来时，大家最容易被 Server Component 这个概念吸引，因为它看起来像是在重新分配前后端渲染责任。但真开始上手以后，我觉得最难的不是语法本身，而是组件边界要重新思考。

做 React 项目时，很多人很自然会把“能不能复用”当成组件拆分的第一原则。但到了 React 18 这种并发渲染语境下，我越来越觉得，组件的渲染责任是否清晰，很多时候比复用程度本身更重要。