React 18 里 transition 和紧急更新怎么分

React 18 的并发能力第一次接触时最容易让人兴奋，但真正写进业务后，我觉得最难的不是 startTransition 这个 API，而是你到底知不知道哪些更新应该立刻响应，哪些更新可以稍微“让一下”。

我更习惯把状态变化分成两类。第一类是用户正在交互时必须马上看到的，比如输入框内容、按钮点击反馈、开关状态，这些都属于紧急更新。第二类是列表重算、搜索结果切换、复杂筛选刷新，这些更适合放进 transition，让界面在重任务执行时还保留交互响应。

如果这两类状态混在一起，就会出现奇怪的问题：要么页面还是卡，要么用户感觉操作没有被及时响应。React 18 给了我们区分优先级的能力，但前提是开发者先想清楚“什么是用户眼里的即时反馈”。

我觉得 transition 不是性能银弹，它更像一个边界提示器。只要你分不清交互反馈和内容重算，API 再新也帮不了太多。先把更新优先级认清，再谈怎么用并发能力提体验。

React 18 真正带来的，不只是性能优化工具，而是更细的交互判断方式。这个判断做得准，页面才会显得稳。

前端里的很多“体验问题”本质上都是边界问题

围绕「React 18 里 transition 和紧急更新怎么分」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。