React性能优化有哪些手段

React 应用变慢，通常慢在哪几处

React 项目的性能问题往往不是单点，而是几类反模式叠加：异步请求一个接一个串行执行，形成"数据水瀑"，首屏迟迟出不来；第三方库和大组件全量打进首屏 bundle，下载和解析都拖慢加载；组件因为对象引用变化反复重渲染，列表一滚就卡；还有布局抖动、热路径里反复读写存储等隐性开销。这些问题分散在数据请求、打包、渲染、JavaScript 热路径等多个层面，靠零散经验很难一次盘清。

这个技能能帮你检查和修什么

它把 Vercel 团队的 62 条规则按八个维度组织起来：消除数据水瀑、减小 bundle、服务端性能、客户端数据请求、重渲染优化、渲染性能、JavaScript 热路径和高级模式。每条规则都按影响优先级排序，配有可定位的示例。实际使用时，它会针对你的代码或问题，指出命中的反模式，并给出对应做法——比如用 Promise.all 或 Suspense 把串行请求并行化；用直接导入、动态导入、延迟加载第三方库来压低 bundle；优化服务端缓存、RSC 序列化和 Server Action 认证；减少无效重渲染、布局抖动、存储读取和数组热路径开销；以及用 SWR、Map/Set、稳定订阅等高级模式收尾。

把规则按影响优先级排序的意义在于：性能优化的投入产出差异很大，先改最影响首屏和交互的项，再处理次要项，比无序地逐条试效率高得多。

怎么用它

用法是把要写的组件、要审查的代码或遇到的性能现象用自然语言描述给它，由它对照规则定位问题、给出优化方向。例如可以这样对它说：

它适合这些场景：新写 React 组件或 Next.js 页面时预防性能反模式；审查代码时发现首屏慢、交互延迟、请求串行或包体过大；重构客户端状态、Effect 依赖、回调订阅和派生状态逻辑；以及需要按规则文件定位具体示例、形成可执行的优化清单。适合 React/Next.js 开发者、前端性能工程师、技术负责人和代码审查者，用来建立统一的重构与性能评估标准。

大家常问

React 应用为什么会出现重渲染导致的卡顿，根因通常出在哪几处？

多数卡顿来自不该变的东西变了：状态提升得太高、内联函数/对象每次渲染都生成新引用、Context 值变化牵连全体消费者、列表用 index 当 key、父组件渲染带着子组件无条件重渲。排查时从最小粒度组件向上追溯哪些 props 在做无效更新。

React 里的 useMemo 和 useCallback 有什么区别，分别在什么情况下才值得用？

useMemo 缓存计算结果（值），useCallback 缓存函数引用，后者其实是前者的特化。它们都有成本，不该默认就加。只有计算开销大（如上万条数据筛选排序）时用 useMemo；函数作为 props 传给被 memo 包裹的重渲染子组件、或作为 Effect 依赖时才用 useCallback。

React 里说的"数据水瀑"是什么意思，为什么它会拖慢页面首屏？

数据水瀑指请求之间存在串行依赖：后一个请求要等前一个返回才发出，层层叠加。它让首屏耗时变成所有请求时间的累加和，而非最大值——三个各 200ms 的请求串起来要 600ms，并行只需 200ms。把彼此不依赖的请求并发化，或让后端一次返回，就能消除。

React 的 useEffect 依赖数组写不对会怎样，为什么对象引用变化会导致副作用反复触发？

依赖写错可能读到旧值、做无效重跑，最棘手的是把对象/数组/函数当依赖引发死循环。React 用 Object.is 比引用而非比值，内容相同的两个新对象也判为"变了"。组件每渲染一次就新建一个对象，于是副作用反复触发。把用到的原始属性拆出来当依赖，或用 useMemo 稳定引用即可。