并发渲染时代组件拆分比组件复用更值钱

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

一个组件如果同时负责取数、状态切换、列表渲染和局部交互，那么它就算被复用到很多页面，也很可能成为性能和调试上的共同负担。反过来，哪怕某些子组件暂时只在一个页面出现，只要它把渲染边界和责任切得清楚，后面维护成本就会低很多。

并发渲染并不会自动帮你解决架构问题，它只是把原本混杂在一起的更新优先级和渲染链路暴露得更明显。组件职责如果不清楚，界面卡顿、状态错位和局部闪烁都会更难解释。

所以我现在拆组件时，先问的是“这个组件该负责哪一层渲染责任”，而不是“能不能提前抽象成通用块”。责任清楚以后，复用反而更自然；责任不清楚时，复用通常只是把问题复制到更多地方。

React 18 不是在逼我们写更多组件，而是在提醒我们：组件边界应该服务于渲染稳定性，而不是只服务于抽象欲望。

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

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

我会先做的落地检查

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