1、React性能优化概述：为什么需要性能优化、性能优化的核心原则、性能优化的常见误区

为什么我们需要谈性能优化？

说实话，我刚入行那会儿，觉得React性能优化是个「高级话题」。那时候写组件，能跑就行。直到有一次，我负责一个数据大屏项目——页面里塞了上千个图表组件，每次数据刷新，页面直接卡成PPT。

嗯，那次经历让我明白了一个道理：React虽然快，但它不是魔法。你写得不小心，它照样会卡。

性能优化，说白了就是解决两个问题：

• 渲染太多——组件明明没变化，却反复重新渲染
• 渲染太重——一次渲染要算半天，用户等得心焦

你想想看，用户打开你的页面，等了3秒还没反应，他会怎么想？大概率直接关掉走人。有数据显示，页面加载时间每多1秒，转化率就下降7%。这不是小事。

性能优化的核心原则

我在项目中踩过不少坑，总结下来，性能优化其实就三条原则。记住了，基本不会跑偏。

原则一：不要过早优化

这句话你可能听过很多遍了。但我还是要强调：先写对，再写快。

我记得有个同事，刚学React，写个简单的TODO列表，就开始用useMemo、React.memo，把代码搞得特别复杂。结果呢？性能没提升多少，可读性却降了一大截。

正确的做法是：先用Profiler跑一遍，找到真正的瓶颈，再动手优化。别凭感觉瞎猜。

原则二：减少不必要的渲染

React的diff算法虽然快，但也不是免费的。每次setState，都会触发整个组件树的重新渲染。如果某个子组件根本没变化，那这次渲染就是浪费。

怎么减少？核心思路就两个：

• 控制状态的作用域——状态放在需要它的最小组件里，别一股脑全塞到顶层
• 使用缓存机制——React.memo、useMemo、useCallback，该用就用

原则三：优化渲染成本

有些渲染是躲不掉的。比如列表数据真的变了，那组件必须重新渲染。这时候怎么办？想办法让每次渲染「轻一点」。

常见的做法：

• 虚拟列表——只渲染可视区域内的元素
• 懒加载——图片、组件按需加载
• Web Worker——把计算密集的任务丢到后台线程

性能优化的常见误区

这部分我特别想聊。因为我自己就犯过不少错，也见过很多人走弯路。

误区一：滥用React.memo

很多人觉得，给每个组件都包一层React.memo，性能就上去了。其实恰恰相反。

React.memo本身也有开销——它要做浅比较。如果组件的props每次都变，那这个比较就白做了，反而拖慢了速度。

正确的用法：只对那些「props稳定、渲染成本高」的组件使用React.memo。

误区二：把所有状态都放到Redux里

Redux是个好东西，但别滥用。有些状态只是组件内部用的，比如表单输入、弹窗开关，完全没必要放到全局store里。

为什么？因为Redux的dispatch会触发所有connect组件的更新。哪怕你的状态只影响一个组件，其他组件也会跟着重新渲染。

我的建议：能用useState就别用Redux。只有那些「跨组件共享、需要持久化」的状态，才考虑放到全局store里。

误区三：盲目使用useMemo和useCallback

这两个API，很多人用错了。以为用了就能提升性能，其实有时候反而更慢。

来看个例子：

// ❌ 错误用法：每次渲染都要计算依赖数组，得不偿失
const value = useMemo(() => a + b, [a, b]);

// ✅ 正确用法：计算开销很大时才用
const sortedList = useMemo(() => {
  return list.sort((a, b) => expensiveCompare(a, b));
}, [list]);

记住一句话：useMemo和useCallback是用来「避免重复计算」的，不是用来「避免重新渲染」的。它们只是工具，不是银弹。

误区四：只看加载速度，忽略交互性能

很多人优化性能，只盯着首屏加载时间。但用户真正在意的是「交互流畅度」。

比如：

• 点击按钮后，页面多久才有反馈？
• 滚动列表时，会不会掉帧？
• 输入框打字时，会不会卡顿？

这些「交互性能」往往比「加载性能」更影响用户体验。我建议你用Chrome的Performance面板多跑跑，看看有没有长任务（Long Task）阻塞了主线程。

小结

这一章我们聊了：

• 为什么需要性能优化——用户等不起，业务伤不起
• 三个核心原则——不要过早优化、减少不必要渲染、优化渲染成本
• 四个常见误区——滥用memo、滥用Redux、滥用useMemo、忽略交互性能

下一章，我们会深入React的渲染机制，看看组件到底是怎么「画」出来的。理解了底层原理，你才能写出真正高性能的代码。

嗯，先消化这些吧。有问题随时问我。