企业官网建设流程全解析

做过 React 项目的同学，大概率都遇到过这样的场景：功能不复杂，数据量也不算大，但只要某处 state 一更新，整个页面就像被按了慢放键，输入框敲字都卡。刚开始我以为是 React 虚拟 DOM diff 太慢，后来把 shouldComponentUpdate 翻来覆去地加，代码丑得自己都不忍直视，性能却没什么起色。直到我花了一整个下午去逐层排查组件的渲染链路，才意识到问题根本不是 React 本身，而是组件设计和通信方式把渲染范围撑得太大了。

这篇文章我想把这两年做 React 项目踩过的坑和总结出来的方法论一次性聊透。主题就是标题里那三件事：性能优化、组件设计模式、组件通信。它们表面上是三个话题，实际是一个问题的三个侧面——组件之间怎么通信，决定了状态在哪个范围变化；状态在哪个范围变化，决定了哪些组件要重新渲染；哪些组件要重新渲染，决定了你的页面快不快。想通这条链路，性能优化就不再是堆 memo 和塞各种缓存，而是从设计源头把开销控制住。

适合的读者：正在做中型以上 React 项目的开发者，对 Hooks、Context 有基础了解但觉得性能优化无从下手的朋友，以及准备面试想把这几个知识点串成体系的人。全文我会按"问题根源 → 设计模式 → 通信方案 → 渲染层实战 → 真实排查案例"的顺序来讲，尽量多给可以直接实操的细节。

1. 性能问题的根源：不是 React 慢，而是你让它白干了太多活

1.1 一次 setState 之后，React 究竟在忙什么

要谈性能优化，先得把 React 的渲染机制搞清楚。这里说的"渲染"不是浏览器重新绘制页面，而是 React 内部的一次"协调"过程：当某个组件的 state 或 props 发生变化，React 就会以这个组件为起点，向下递归地执行 render 函数，生成一棵新的虚拟 DOM 树，然后和上一次的树做 diff，找出差异，最后才把差异提交给真实 DOM。

这里有个关键点很多人没意识到：React 默认是"无脑"的。父组件重新 render 了，子组件就算 props 一点都没变，也会跟着重新执行 render。这个"跟着执行"本身没有错，React 要靠这个来保证数据一致性，但如果你的组件树很大、子组件很多、每个 render 里还有复杂的计算和嵌套对象创建，那一次 state 更新可能触发几百个组件的 render 函数执行。哪怕每个组件执行只要零点儿几毫秒，加起来一次交互就得多花几十甚至上百毫秒，用户感知到的就是卡顿。

打个比方，React 的默认行为就像一个快递公司，任何一个小包裹到了，不管是不是你的，都要把所有快递员叫醒检查一遍货架。大部分时候这些检查都是徒劳的，但公司为了不出错，宁可每次都全员出动。

1.2 三个最容易忽视的性能杀手

我排查过不少线上性能问题，总结下来，绝大多数卡顿都离不开下面三个原因：

第一，状态放得太高。很多开发者习惯把所有数据都放在顶层组件里管理，然后通过 props 一层层往下传。这样做的后果是：任何一个底层子组件想更新某个局部数据，都得把状态提升到顶层，然后再让整棵组件树重新渲染一遍。这种设计的本质问题，是把通信成本和渲染范围同时拉满了。

第二，Context 滥用。Context 是官方提供的跨层级通信方案，但它的价值语义在 React 内部其实很简单——只要 context value 变了，所有订阅了这个 context 的组件都会强制重新渲染，不管它们是否真的用到了变化的那部分数据。很多人把整个 store 对象塞进 context value，导致任何一个小字段的更新都引发全局刷新。

第三，render 函数里产生新引用。这是最常见也最隐蔽的问题。比如在 render 里直接写<Child onClick={() => handleClick(id)}>，或者写const style = { color: 'red' }，又或者对一个数组做.filter()之后传给子组件。这些操作每次 render 都会生成全新的对象引用，如果子组件恰好被 React.memo 包裹了，恭喜你，memo 全部失效。

这三个问题后面都会展开。先记住一个核心理念：性能优化不是让 React 跑得更快，而是让 React 尽量少跑。

2. 组件设计模式：从源头控制渲染范围

2.1 容器组件与展示组件拆分：把"变"和"不变"隔离

容器组件和展示组件的拆分是我早期做 React 最受益的一个模式，到现在依然是很多团队的基础规范。核心思想很简单：把组件的"数据逻辑"和"UI 呈现"分开，容器组件负责状态管理和数据获取，展示组件只负责根据 props 渲染界面。

为什么这个模式对性能有好处？因为拆分之后，你可以更精细地控制"谁该重新渲染"。数据更新通常只发生在容器组件那一层，展示组件如果 props 没变化，就能被 React.memo 完好地挡在渲染之外。如果不拆分，把状态和 UI 混在一起，状态一更新，整个组件连带它所有的子组件全部重新 render，完全没有隔离的余地。

举个例子，一个商品列表页，有筛选条件、排序方式、商品卡片。如果所有状态都堆在列表页组件里，用户点一下排序，整个列表页从头部导航到页脚全部重新渲染。而如果用容器组件包住筛选逻辑，用展示组件分别渲染列表头和商品卡片，那么排序状态变化时，只有列表容器和它直接依赖的展示组件会更新，其他区域毫发无损。

当然，这个模式也有过度应用的时候。组件拆得越细，props 就越多，通信代码就越冗长。我的经验是：拆分不是为了代码漂亮，而是为了控制渲染范围和复用边界。如果一个展示组件内部只有几十行、没有重复使用的地方、父组件的更新频率也不高，那拆不拆无所谓，别为了模式而模式。

2.2 从 HOC 到 Hooks：设计模式的演进与取舍

React 社区这些年围绕着"怎么复用逻辑"演化出了好几种模式：Mixin、高阶组件（HOC）、Render Props、自定义 Hooks。每次演进都是对上一次缺点的修正，理解这个过程能帮你避开很多历史坑。

HOC 的本质是"包装组件"。函数接收一个组件，返回一个增强后的新组件，常见应用是权限校验、埋点上报、拉取数据然后注入 props。它的性能隐患在于：每次 render 时如果动态创建 HOC，会导致被包装组件重新挂载。比如你在 render 里写withAuth(MyComponent)，每次 render 都会创建一个新的组件类型，React 会认为这是完全不同的组件，直接卸载旧的再挂载新的，状态丢失、性能暴跌。正确做法是在模块顶层创建 HOC，保证组件类型的引用稳定。

Render Props 通过一个函数 prop 把状态传给子组件，解决了 HOC 的部分问题，但写法嵌套一多就容易变成"回调地狱"，而且同样存在 render 函数里产生新函数引用的问题。

Hooks 为什么是终极方案？因为它把逻辑复用提升到了"函数"层面，而不是"组件"层面。你不再需要包装组件，也就不会引入多余的组件层级，渲染树的深度变浅了，React 协调的开销天然就小。自定义 Hook 还可以非常精准地控制副作用和缓存的粒度。所以新项目我几乎全部推荐 Hooks，HOC 和 Render Props 了解原理、能维护旧代码就够了。

2.3 组合优于继承：组件拆分粒度的把握

设计组件树的时候，很多人容易犯一个错误：为了复用某些 UI 片段，把组件拆得非常碎，然后通过多层 props 一层层传数据。结果渲染的时候，从根组件到叶子组件可能要经过五六层 props 透传，每一层都要重新 render，每一层都要传递大量 props——这就是典型的"过度拆分"。

React 官方的建议是"组合优于继承"。所谓组合，指的不是嵌套传 props，而是用 children 或 slot 机制把子组件直接作为整体传入。这样做的好处非常明显：父组件更新的 props 不会穿透到 children 内部去。举个典型的例子，一个 Dashboard 布局组件，左边是菜单，右边是内容区。如果用 props 把菜单数据和内容数据都传进去，任何一边更新都会带动整个布局重新渲染。但如果你用 children 把菜单和内容作为整体传进来，那么只要布局组件自身状态不变，children 引用不变，React 就能跳过整个子树的重渲染。

这里面的关键在于 children 本身也是一个对象引用。父组件 render 时，如果 children 是上一次 createElement 的结果（引用没变），React 就会认为这棵子树不需要重新协调。所以我在实际项目里经常这样写：状态变化只发生在布局这一层，但 children 是从外部传入的，那么布局层的重新渲染不会波及内容区。这个模式对"页面框架类组件"的优化效果极其显著。

3. 组件通信的选型与实现：不同距离用不同方案

先说一句题外话。很多人会把 React 组件通信和 Electron 主进程与渲染进程的 IPC 通信混为一谈，其实它们层级不同——前者是 React 应用内部的状态数据流，后者是 JavaScript 运行环境之间的进程通信。但两者有个共同点：通信方式选不好，各自层的性能都会崩。Electron 里主进程和渲染进程之间用 IPC 还是直接共享状态，决定了渲染进程会不会被主进程的每一条消息拖住；React 里组件之间用 props、Context 还是状态库，决定了状态更新会波及多大范围的组件。所以在做技术选型时，先问一句"这个数据到底需要影响多少人"。

3.1 父子通信：props 和回调函数的正确姿势

最基础也最容易被忽视的就是父子通信。父传子用 props，子传父用回调函数，这谁都知道，但"怎么传"直接影响性能。

先说 props。要保证子组件能享受 React.memo 的跳过渲染优化，父组件传给子组件的 props 引用必须稳定。字符串、数字、布尔值这种原始类型天然稳定，但对象、数组、函数就不一样了。在 render 函数里直接创建对象字面量、数组字面量、箭头函数，每次 render 都是新的引用，React.memo 对比新旧 props 时会发现引用不等，于是白白触发子组件重渲染。

正确的姿势是把函数用useCallback包起来，把复杂对象用useMemo缓存，或者干脆把函数定义提到组件外部（不依赖 props 和 state 的纯函数才适合这么做）。另外一个思路是：如果子组件只需要原始值，就别把整个对象传下去，拆成单个原始值传。比如只需要user.name和user.isVip，那就直接传这两个字符串和布尔值，别传整个user对象，这样即使父组件的user对象变化了，只要这两个字段没变，子组件就能被 memo 挡住。

再说回调。子组件通过 props 里的回调通知父组件，这种模式在通信距离只有一层时是最清晰的，性能开销也最小，因为数据流的走向一目了然，状态在哪个组件、更新会触发哪些渲染，都能顺着代码追踪。需要注意的坑是：给子组件传多个回调时，不要贪图方便传一个 dispatch 或 update 函数，让子组件自己拼参数。那样看似灵活，实际上把状态更新的逻辑分散到子组件里了，将来排查谁改了这个状态会非常痛苦。

3.2 跨层级通信：Context 的性能陷阱与优化

当数据要跨三层以上传递时，逐层 props 穿透就成了灾难——中间层的组件既不使用这些数据，却要为了传递而被迫重新渲染。Context 就是为解决这个场景而生的，但它的性能问题也恰恰出在这儿。

Context 的工作机制是：Provider 的 value 引用一旦变化，所有消费这个 context 的组件都会强制重新渲染。注意这个"所有"，它是无差别的，不会因为你用了 React.memo 就帮你挡掉——memo 在 context 面前是失效的，因为消费组件不是因为 props 变化而重渲染，而是因为 context 订阅被触发了。

所以使用 Context 的第一个铁律：value 必须用 useMemo 缓存，并且粒度拆分清楚。别把整个 store 对象作为 value 传下去，应该拆成多个 context，或者让 value 只包含真正会变化、且消费方确实需要的那部分数据。举个例子：主题色 context 和用户信息 context 就应该分开，主题色变化时不需要让用户信息相关的组件跟着重新渲染。

第二个铁律：Provider 的位置尽量靠近消费方。Context 的层级越高，受影响的组件树就越大。如果一个数据只被某个页面的某几个组件使用，那 Provider 就放在那个页面的上层，而不是挂在全局的根组件上。很多团队默认把 App 的根组件包一层全量 Provider，结果任何一个全局状态更新，整个应用全部刷新，这是我在真实项目里见过最严重的性能事故之一。

第三个进阶技巧：如果确实需要把一部分数据放全局，但又不希望全局组件全部重渲染，可以考虑用一个"状态选择器"的机制——把 context 拆成两个：一个存数据本身，一个存 setter 函数。setter 的引用保持稳定（用 useCallback），这样消费组件订阅的是 setter 的 context，数据更新时它们不会重渲染。这个模式在 Zustand 等状态库里有现成的 selector API 帮你做，但如果用原生 Context，就得手动控制这个粒度。

提示：原生 Context 没有内置 selector 能力，每次读取都是按引用消费。如果你对渲染性能要求很高且状态较复杂，优先考虑 Zustand 这类轻量状态库，它们提供了非常精确的订阅机制，能在组件粒度上避免无效渲染。

3.3 全局通信：事件总线与状态管理库的差异化选择

有些场景是真正需要"全局"通信的：用户登录状态、购物车数据、全局的 toast 通知、多模块之间互相联动。这类信息的传播路径往往很广，用 Context 或 props 都不太合适。这时候通常有两个方向：事件总线和状态管理库。

事件总线（比如 mitt、EventEmitter）的思路是发布订阅，任意两个模块可以通过事件名通信。它的优点是使用极其灵活、通信和 UI 完全解耦，缺点是状态不透明——事件发出去了，谁听了、谁改了、数据从哪来到哪去，都要靠人肉维护，大型项目里很容易失控。而且事件总线的数据更新不会自动和 React 生命周期绑定，需要手动触发 setState，稍不留神就会引入额外的渲染或漏更新。

状态管理库（Redux、Zustand、Jotai、Recoil）本质上是把全局状态和组件订阅做了工程化的管理。我最推荐在当前新项目里用 Zustand，原因有几个：Redux 的样板代码太多，action、reducer、selector 层层包裹，对中小组件来说太重；Zustand 的 store 可以在组件外部直接创建和更新，组件通过 hook 按需订阅字段，内部实现了精确到字段的订阅比较，避免了整个 store 更新引发全应用刷新的问题；样板代码极少，天然支持依赖外部 store 的状态——这一点在处理 WebSocket 推送的场景里特别香。

选用状态库的时候，注意两个性能关键点：一是订阅粒度。Zustand 默认按 selector 返回值做浅比较，如果你在 selector 里返回一个每次新建的对象（比如state.user.profile），它会因为引用变化而陷入无限渲染循环或频繁重渲染；正确的姿势是选择器返回原始值，或者借助useShallow做浅层比较。二是避免把 store 塞进 Context。Zustand 的 store 是模块级单例，组件直接 import 后 useStore，根本不需要 Provider，这又省掉了一层 context 消费者重渲染的开销。

3.4 服务端通信：SSE 和 WebSocket 场景下的组件更新策略

现在前后端分离的应用里，实时通信越来越常见，SSE 和 WebSocket 已经是标配。它们对 React 组件通信的影响很少有人专门聊，但实际踩坑的人非常多。

先说 WebSocket。很多人习惯把 WebSocket 实例放在组件的 useEffect 里创建，然后在 onmessage 回调里直接 setState。这种写法最大的问题是：连接的生命周期和组件的挂载卸载耦合，组件一卸载连接就断，重新挂载又重连，而且每个创建连接的组件都会拿到自己的回调闭包，状态更新容易互相覆盖。我在做实时数据大屏的时候就吃过这个亏。

稳妥的方案是把 WebSocket 的管理抽象成一个独立的服务模块，用事件或状态库来做数据分发。连接只在应用层面建立一次（比如做了一层connect()初始化），收到消息后更新 Zustand store，然后各个组件通过 selector 订阅自己关心的字段。这样通信的职责是统一的，组件只关心"数据来了之后我该渲染什么"，不关心"数据是怎么来的"。同时，由于 store 的订阅是字段级的，一条消息过来，只有关心这个字段的组件会更新。

再说明一下 SSE。它是基于 HTTP 的单向流，只推送不接收，所以比 WebSocket 简单得多，常用于文件上传进度、服务端日志流、通知推送这类场景。React 侧的接法也类似：用 useEffect 创建 EventSource，收到 message 后更新局部 state 或者写入 store，组件卸载时记得 close，否则内存泄漏和重复监听会让性能逐渐恶化——这个坑我在线上遇到过，打开页面又关掉几次，EventSource 攒了一堆，后台请求越积越多，最后浏览器连接数被占满，新请求全部卡住。

如果你的场景里有"轮询文件变化"这类需求，建议把"轮询"和"推送"做个区分：轮询适用于服务端无法主动推送的场景，但轮询间隔设置得太短会白白消耗带宽和 CPU；如果服务端支持 SSE 或 WebSocket，优先用推送，把轮询作为降级方案。前端实现时，把数据到达后的状态更新收敛到一个地方（比如统一的 store action），避免多个组件各自监听各自 setState 造成的重复渲染。

4. 渲染层优化：memo、缓存、懒加载的实战细节

4.1 React.memo 不是万能药，用对才有意义

React.memo 是函数组件的浅比较缓存，只有 props 变化时才会重新渲染。听起来很美好，但实际项目中 memo 失效的场景占大多数，原因就是我在前面反复提到的"引用不稳定"。

典型场景如下：

// 父组件 function Parent() { const [count, setCount] = useState(0); return ( <Child data={{ count }} /> ); }

父组件每次 render 都创建一个新的对象{ count }，即使 count 没变，子组件也会重渲染，因为 props 的引用每次都不同。这个模式下，Child 加不加 memo 都一样。

正确的做法之一是把对象创建移到 useMemo：

const data = useMemo(() => ({ count }), [count]);

之二是干脆拆开传原始值：

<Child count={count} />

所以我在团队评审代码时有个习惯：看到别人的 memo 不生效，第一反应不是怀疑 memo 有没有用，而是先去看上游组件传给它的 props 是不是在 render 时新建了引用。memo 的意义是在"props 引用稳定"的前提下减少无效渲染，它本身不能修复引用不稳定的问题。

另外要注意，memo 也不是越多越好。对于本身渲染成本极低、又经常因为父组件变化而需要同步更新的组件，包一层 memo 反而增加对比开销。经验法则：一个组件内部有复杂的计算、或者子树庞大、或者列表项很多，才值得用 memo。简单的图标、按钮、文本节点，别太执着。

4.2 useMemo 和 useCallback：缓存的是引用，不是计算

useMemo 和 useCallback 经常被误用。它们本质是"依赖不变则引用不变"的缓存工具。useCallback 就是 useMemo 的语法糖：useCallback(fn, deps)等价于useMemo(() => fn, deps)。

最常见的误用是：为了"缓存计算结果"而包裹所有计算，结果发现依赖数组里塞了一大堆东西，每次 render 依赖都变化，缓存完全失效，还额外执行了一次依赖比较。这个问题的根源是没搞明白 useMemo 的价值场景。useMemo 真正适合的场景是"昂贵的计算"，比如遍历几千条日志、处理大量坐标点、复杂的字符串拼接。如果你的计算只是生成一个短字符串或者一个小数组，useMemo 的意义不大，因为 JS 引擎执行这些操作非常快，比 useMemo 自身的开销还小。

更常见的价值其实是引用稳定。真正需要 useMemo 的场景是：你有一个数组或对象要传给子组件，而这个派生逻辑又依赖一些可能变化的状态，这时用 useMemo 保证"依赖没变时引用不变"，从而让子组件的 memo 可以生效。这才是 useMemo 的主要用途——不是省计算，而是省渲染。

useCallback 也一样。传给子组件的回调函数应该尽量稳定，尤其是配合 memo 的子组件。但我见过不少人把 useCallback 包在根本没有子组件消费的函数上，纯粹为了形式。记住：没有消费方，缓存就没有意义，只会白白增加闭包和依赖管理的复杂度。

依赖数组的填写是个容易出错的细节。漏掉依赖会导致闭包捕获旧的 state，行为错误；填太多又会导致缓存失效。我的建议是写依赖的时候想想：这个函数或数据真正依赖外部变化的变量有几个？state 和 props 中哪些会影响结果？只填这些。同时，灵活运用函数式更新：setCount(c => c + 1)这种写法不依赖外部 count，是保持回调稳定的利器。

4.3 大列表渲染：虚拟滚动、Key 策略和渲染时机

前端性能优化的重灾区永远是大列表。几千上万行的表格或日志，如果每行都是一个组件，一次渲染基本就卡死了。这里有三层手段可以叠加使用。

第一层是虚拟滚动。react-window 和 react-virtualized 这两个库直接用视口高度计算可视区能容纳多少行，只渲染可视区附近的组件，滚动时动态替换。注意 react-virtualized 几乎已经不再维护，新项目直接用 react-window 就好。它有两种形态：FixedSizeList 适合行高固定的场景，VariableSizeList 适合行高不定的场景。使用的时候有细节：列表数据更新时，如果数据总量变化，要显式给列表设置 key 或调整 overscan 数量，不然可能出现滚动位置错乱。

第二层是Key 策略。列表项的 key 必须稳定且唯一，我建议用业务 id，而不是数组索引。用索引当 key 的问题在于：当你删除或插入列表项时，React 复用组件时会遇到序号错位，导致组件内部状态（比如输入框的内容、展开的折叠状态）串到别的行上，而且常见的"删除中间一项后整个列表卡顿"很大程度也是因为 key 用了索引，React 不得不重新执行一串组件的挂载。

第三层是渲染时机。列表本身如果不需要实时更新，就不该放在高频状态变化的作用域下。比如一个数据监控页面，图表区每秒刷新数据，但日志列表是 5 秒刷新一次，那就让日志列表用 useMemo 包住它的数据源，或者干脆把列表做成独立容器组件，避免被图表区的 state 更新波及。

还有一个常见优化是把"计算"挪到渲染之外。比如列表项里做了字符串拼接、日期格式化、数据过滤，这些操作如果每次 render 都做，很快就成了性能瓶颈。要么在数据源更新时就预处理并缓存，要么用 useMemo 按依赖缓存。千万别在 render 里直接写一个.map().filter().reduce()长链条，然后每次全量执行。

4.4 代码分割与 Suspense：首屏快，后面才能稳

优化不能只盯着运行时，体积也是一大部分。一个 React 应用如果把所有页面、所有库都打进一个 bundle，首屏加载就得下载几百 KB 甚至上 MB 的 JS，白屏时间长，这在弱网环境下尤其致命。对了，Web 端这个痛点和移动端 React Native 的启动白屏其实是一类问题——核心都是"启动时需要执行/加载的内容太多"，解法思路也相通：能延迟的就延迟，能拆分的就拆分。

代码分割的方案是动态 import。React.lazy 配合 Suspense 可以按路由或按组件懒加载。基础写法：

const Dashboard = React.lazy(() => import('./pages/Dashboard')); function App() { return ( <Suspense fallback={<Loading />}> <Dashboard /> </Suspense> ); }

实际项目里需要注意的细节有几个：一是 Suspense 的边界，尽量让 fallback 的粒度小一些，只在真正需要加载的子树外面包一层，否则一个懒组件加载失败（比如网络错误）时，整个页面的 fallback 一起闪。二是 React.lazy 只适用于默认导出的组件，命名导出需要包一层转换。三是结合构建工具的 prefetch 和 preload 策略，让用户点击路由之前提前加载，点击之后几乎零等待。

还有一个常被忽略的点：第三方库按需引入。比如用 lodash 就用lodash-es并只 import 用到的函数；用 antd 就按需引入组件和样式。Tree shaking 和 sideEffects 配置不处理好，打包体积会莫名膨胀。我见过一个项目，只是用到了一个日期处理函数，结果整个 lodash 被打了进去，首屏多了几十 KB，原因就是构建配置里的 sideEffects 没有正确开启。

5. 一次真实的重渲染问题排查全过程

5.1 问题表象：页面操作越来越卡，越用越慢

说一个我去年实际遇到的项目场景。那是一个数据中台系统，页面结构：左侧导航、顶部工具条、中部是复杂的表格和图表。用户反馈：在顶部工具条里切换筛选条件后，表格数据更新非常慢，而且页面整体有种"黏滞感"，点哪里都像有延迟。

我打开 Chrome DevTools 的 Performance 面板录制了一段操作，发现单次筛选切换，主线程占用接近 800ms，其中大量时间消耗在 React 的 re-render 阶段，渲染组件数量超过上千个。一眼望去就知道这不是某一道算法卡住的问题，而是所有组件全被殃及了。

5.2 用 Profiler 一步步缩小范围

我改用 React DevTools 的 Profiler 来定位。先开着 Profiler 做一次筛选操作，然后看火焰图里哪些组件被标记为渲染。结果触目惊心：几乎从头到尾所有组件都亮了一遍，包括左侧导航、顶部工具条这种和表格数据毫无关系的组件，也在重新 render。

这时候就发现了两个问题。第一个：表格数据的 store 是通过顶层 Context 提供的，Provider 挂在根组件上。筛选条件一变，store 更新，整个 context value 的引用跟着变化，所有消费方全部重渲染。第二个：顶部工具条的筛选条件是放在工具条自己内部 state 里的，但它的某些 props（比如一个 options 数组）是在父组件 render 时用.filter()现场创建的，导致工具条内部那些 memo 过的子组件也全部失效。

这个案例里通信和设计的问题交织在一起，正好印证了我前面说的：很多性能问题的根源在组件通信方式（Context 范围太大、回调引用不稳定）和组件设计（把不相关数据放在同一作用域）上。

5.3 修复方案与最终效果

修复工作分几步做。第一，把 Provider 从根组件往下挪，放到真正需要共享数据的页面容器上，减小传播范围。第二，拆分 Context——表格数据、用户信息、主题设置各成一个 Context，互不干扰。第三，对工具条组件内部做改造，把 options 数组的创建放到 useMemo 里，依赖只是筛选值本身；回调函数用 useCallback 稳定引用。第四，表格容器本身包一层 React.memo。

改完之后用同样的操作再录一次 Performance：单次筛选主线程占用从 800ms 降到了 120ms 左右，渲染组件数从上千个减少到几十个。用户反馈"黏滞感"完全消失。这次排查给我的教训很深：优化性能之前，先追溯"这个消息是从哪发出、经过了哪些组件、影响到了哪些消费者"，把通信路径和渲染范围画清楚，比盲目加 memo 有用一百倍。

6. 关于性能优化，我最后想说的几句话

玩过一阵子 React 性能优化之后，我的最大体会是：优化不是冲刺跑，而是登山。你不能指望一次大改就把所有问题解决，因为业务是活的，组件在持续增加，通信关系在持续变化，渲染路径随时会冒出新的问题。你也不该过早地给每一行代码套上 memo 和 useMemo，那样代码可读性会被毁掉，真正的问题并不会因为缓存变多而消失。

我更推荐的做法是把性能意识内化到日常编码习惯里：状态尽量放在局部，Provider 尽量靠近消费方，传给子组件的引用尽量稳定，列表 key 用业务主键，数据流向尽量单一清晰。这些习惯不费多少精力，却能从源头挡住大部分性能问题。等真正遇到卡顿，再用 Profiler 去定位、用各种优化手段去修复，这样才不会把代码改得面目全非。

如果你正在准备面试，这篇文章里涉及的点——组件设计模式、通信方案、渲染优化的原理——恰好是可以串成一条线来讲的知识体系。面试官问 React 性能优化，别只背 memo 是什么，试着从"状态放哪儿、消息怎么传、渲染范围多大"这个角度去回答，会让你的思路显得成熟很多。同样的逻辑也适用于很多手写 React 实现的考题，理解了渲染协调和通信机制，手写一个简化版 React 其实就是在复原这套骨架。

最后分享一个我自己一直在用的小技巧：在代码评审时，凡是看到"新创建的引用被传给有 memo 的子组件"这类写法，我都会直接指出来并让作者改成稳定引用。这样做半年后，团队的页面性能问题明显少了很多。性能优化说到底，拼的就是这些不起眼的细节，它们累积起来，就是体验的天壤之别。