React 列表渲染拆分比盲目 memo 更重要

只要页面里有中大型列表，性能问题迟早会出现。很多人这时会本能地去加 memo、useMemo、useCallback，但我越来越觉得，真正决定列表是否好维护的，往往不是有没有做缓存，而是渲染边界有没有拆清楚。

如果列表项依赖了太多外层状态，那你再怎么 memo，也很容易因为引用变化导致整批重渲。相反，如果先把筛选、排序、选中态、工具栏状态和列表项自身展示拆开，很多性能问题在结构层面就已经被削掉了。

我一般会先问几个问题：列表项是否拿到了不该拿的全局状态？一个操作是不是本来只影响局部却触发了整页刷新？渲染慢到底是因为计算重，还是因为边界没收住？这些问题不先搞清楚，后面加再多 memo 都像补丁。

memo 应该是最后一步，而不是第一反应。先把列表渲染拆到合理颗粒度，再考虑哪些地方值得缓存，往往更稳也更容易读。

React 性能优化最怕把技巧当答案。结构先对，技巧才真的有价值。

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

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

我会先做的落地检查

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