React 重新渲染优化实战：别再用 useMemo 兜底了

很多人一提到 React 性能就是一套三连：函数包 useCallback，组件包 memo，值包 useMemo。结果包完没变快，甚至更卡。这篇讲清楚重渲染机制，以及真正有效的优化顺序。

一、先弄清：什么东西会触发重渲染
只有三种：state 变化、props 引用变化、context value 变化。

关键事实：React 默认情况下，父组件一渲染，子组件全都跟着渲染——除非被 memo 包裹。所以"子组件很贵"这个直觉，往往才是优化的真正入口。

二、用 Profiler 说话，别凭直觉
打开 React DevTools 的 Profiler，录制一次交互，看高亮组件的耗时和渲染次数。没有实测就到处 memo，属于瞎优化——优化只能发生在"真的测出了性能问题"之后。

三、优化优先级（从高到低）
1. 状态隔离 + 组件拆分（收益最大）
把频繁变化的状态下放到只管它的子树。比如输入框的 value 状态只留在表单组件里，别放页面上层。变化范围小了，受牵连的渲染自然少。

2. Context 分片
context value 一变，所有消费它的组件全部重渲染。把不相干的 state 拆成多个小 Context，避免一个 setState 把整棵消费树拉下水。

3. useCallback 只配合 memo 使用
memo 能跳过渲染，前提是 props 引用没变。所以规则很清晰：只在给 memo 子组件传函数时，才用 useCallback 包；否则裸写就好，包裹本身也有创建成本。

4. 别在渲染期间新建对象
<Child config={{ a: 1 }} /> 和 <Child fn={() => {}} /> 每次渲染都产生新引用，memo 直接失效。

5. 列表太长就虚拟化
上千行的列表用 react-window / react-virtualized，只渲染可视区内的几十行，这是"量大"场景的唯一正解。

四、正确的优化心态
记住一个不等式：渲染次数多 ≠ 慢。真正拖垮页面的是"单次渲染耗时 x 次数"。用 Profiler 的火焰图找出 Long Task，先把单次慢的组件修好，再谈减少次数。先看病，再开药。

结论：React 性能优化 = Profiler 定位 → 组件拆分隔离 → 精准 memo → 万不得已才虚拟化。