React性能诊断地图：五大杠杆点精准定位瓶颈

1. 这不是“优化清单”，而是 React 性能问题的诊断地图

你有没有遇到过这样的场景：用户反馈列表滚动卡顿，打开 DevTools 的 Performance 面板录一段操作，火焰图里密密麻麻全是黄色的render块，CPU 占用直接飙到 90%；或者某个页面首次加载后，点击一个按钮要等两秒才响应，控制台却没有任何报错；又或者在低端安卓机上，一个简单的表单输入都伴随着肉眼可见的掉帧。这些不是玄学，也不是“React 就是慢”的甩锅，而是性能瓶颈在向你发出明确信号——它就在那里，只是你还没找到它的坐标。

我做过十几个中大型 React 项目，从电商后台到实时数据看板，从金融风控系统到教育类互动课件。最常被问到的问题不是“怎么写新功能”，而是“为什么这个页面越来越卡”。而翻看团队提交记录，往往发现没人动过核心逻辑，只是陆陆续续加了几个 Hook、引入了一个新组件库、多渲染了几行状态相关的 UI。这恰恰印证了一个事实：React 应用的性能退化，绝大多数时候不是由某一行“坏代码”引爆的，而是由无数个微小、合理、甚至“教科书式”的决策，在时间推移和业务叠加中悄然累积而成的。它像温水煮青蛙，直到某天用户忍无可忍地截图发来“卡死了”的反馈，我们才被迫停下开发节奏，一头扎进 Performance 面板里大海捞针。

所以，这篇内容不打算给你一份“复制粘贴就能提速 50%”的魔法清单。那不现实，也容易误导。我要带你做的，是构建一张属于你自己的 React 性能诊断地图。这张地图的核心，是围绕五个最关键的“性能杠杆点”展开：组件重渲染的边界控制、内存泄漏的主动防御、代码体积的精准瘦身、异步渲染的节奏管理，以及状态更新的意图对齐。这五个点，恰好对应着React.memo、PureComponent（虽已不推荐但理解其原理至关重要）、React.lazy/React.Suspense、以及useMemo/useCallback等工具背后的真实战场。它们不是孤立的 API，而是解决特定类型性能问题的“手术刀”。接下来，我会用真实项目中的血泪教训，告诉你每一把刀该切在哪、怎么切、以及切错了会流多少血。

2. 渲染风暴的源头：为什么你的组件总在“无意义地跳舞”

几乎所有 React 性能问题的起点，都指向同一个现象：不必要的重渲染（Unnecessary Re-renders）。它就像一场悄无声息的“渲染风暴”，在你毫无察觉时，让 CPU 和 GPU 持续满负荷运转，只为重新计算和绘制那些根本没变的像素。而这场风暴的燃料，往往就藏在你每天都在写的useState、useEffect和props传递里。

2.1 一个被低估的真相：函数组件的“纯净性”陷阱

在 Class Component 时代，我们习惯于用shouldComponentUpdate来手动控制是否跳过渲染。到了函数组件，很多人理所当然地认为：“函数组件每次都是全新的，所以每次 props 变了就必须重渲染，这是 React 的设计哲学。” 这个理解只对了一半。React 确实会在父组件 re-render 时，无条件地调用子组件函数。但关键在于：子组件函数内部的执行，并不等于 DOM 的更新。React 的 Diff 算法会对比新旧 Virtual DOM 树，如果发现结构和内容完全一致，它就会聪明地跳过真实的 DOM 操作。所以，问题的核心从来不是“函数是否执行”，而是“执行后生成的 JSX 是否与上次相同”。

那么，什么会让 JSX “不同”？最隐蔽的元凶，就是内联函数（Inline Functions）和内联对象（Inline Objects）。请看这个再常见不过的例子：

// ❌ 危险的写法：每次父组件渲染，都会创建新的 onClick 和 style 对象 function Parent({ items }) { const [selectedId, setSelectedId] = useState(null); return ( <div> {items.map(item => ( <Child key={item.id} item={item} // 每次渲染都创建一个新函数！ onClick={() => setSelectedId(item.id)} // 每次渲染都创建一个新对象！ style={{ opacity: item.id === selectedId ? 1 : 0.7 }} /> ))} </div> ); } function Child({ item, onClick, style }) { // 即使 item 没变，onClick 和 style 也永远是新的引用 // 导致 Child 组件每次都“认为”自己需要重渲染 return <div style={style} onClick={onClick}>{item.name}</div>; }

在这个例子中，Parent组件只要自身状态（比如selectedId）一变，它就会重新执行map函数。每一次执行，都会为每一个Child创建一个全新的onClick函数和一个全新的style对象。对于Child组件来说，它的props.onClick和props.style的引用地址，每一次都和上一次不同。即使item数据本身纹丝未动，Child也会被强制触发一次完整的 render 流程。当items数量达到上百条时，这种“无意义的舞蹈”就会让页面明显卡顿。

2.2React.memo：不是万能胶，而是“引用守门员”

React.memo的作用，就是为函数组件装上一道“引用守门员”。它不会改变组件内部的逻辑，也不会阻止函数的执行，它只做一件事：在组件即将进入 render 阶段前，浅比较（shallow compare）本次的props和上一次的props。如果所有props的引用都相等，它就直接跳过本次 render，复用上一次的渲染结果。

这听起来很完美，但它的威力完全取决于你如何使用它。React.memo默认只进行浅比较，这意味着它只检查props对象第一层属性的引用是否相同。对于上面那个例子，onClick和style是第一层属性，所以memo能完美拦截。但如果props里传的是一个嵌套很深的对象，比如user.profile.address.city，memo就无能为力了，因为user对象本身的引用变了，它连第一层都过不去。

提示：React.memo的第二个参数是一个自定义比较函数areEqual(prevProps, nextProps)。当你需要更精细的控制时（例如，只关心user.id变了才更新），可以在这里实现深比较逻辑。但请注意，深比较本身有性能开销，务必权衡利弊，避免“为了优化而制造新瓶颈”。

2.3PureComponent：Class Component 时代的“自动 memo”

PureComponent是React.memo在 Class Component 时代的孪生兄弟。它在shouldComponentUpdate生命周期中，自动为你实现了对props和state的浅比较。如果你的 Class Component 是纯的（即render方法的输出只依赖于props和state，且没有副作用），那么把它从Component改成PureComponent，就能获得和React.memo类似的收益。

然而，在现代 React 开发中，PureComponent已经成为一个“历史遗迹”。原因很简单：函数组件 + Hooks 的组合，提供了更灵活、更细粒度的控制能力。你可以对单个prop使用useCallback，对单个state使用useMemo，而不是像PureComponent那样，对整个props对象进行一刀切的浅比较。后者在某些场景下反而会成为枷锁。例如，一个PureComponent接收了一个onScroll回调，这个回调本身是稳定的，但它的props里还包含一个频繁变化的loading状态。PureComponent会因为loading的变化而强制更新，即使onScroll完全不需要重新绑定。

注意：PureComponent的浅比较是双刃剑。它要求你必须确保props和state中的所有值都是可安全浅比较的。如果你不小心把一个Date对象或一个RegExp对象作为prop传入，由于它们每次创建都是新引用，PureComponent就会失效，甚至可能引发难以追踪的 bug。

2.4 实战心得：memo的黄金使用法则

在我维护的一个大型 CRM 系统中，有一个“客户详情页”，里面嵌套了 12 个独立的子模块（联系人、跟进记录、合同列表、发票预览等）。最初，任何一个小的状态变更（比如切换一个 Tab），都会导致整个页面所有模块一起重渲染，耗时高达 800ms。通过React.memo，我们将这个时间压缩到了 120ms。但这不是靠盲目添加memo实现的，而是遵循了三条铁律：

1. 只对“叶子”组件使用memo：我们只给那些不包含任何状态管理、纯粹负责展示数据的组件（如ContactCard,InvoiceItem）加memo。像TabPanel或DataGrid这种本身就要处理大量内部状态和事件的容器组件，加memo效果甚微，反而增加了心智负担。

2. props必须“稳定”：在给memo组件传prop时，我们强制要求所有函数类型的prop必须用useCallback包裹，所有对象类型的prop必须用useMemo包裹。这已经成为我们团队的代码审查红线。一个没被useCallback包裹的onSave函数，会被 CI 流水线直接拒绝合并。

3. 永远用key配合memo：在map循环中，key不仅是 React 的识别符，更是memo的“信任锚点”。当key相同，React 才会将新旧props传递给同一个memo组件实例进行比较。如果key写成了index，一旦数组顺序发生变化，memo就会彻底失效，因为它面对的是一个全新的组件实例。

3. 内存泄漏的幽灵：那些你以为已经“卸载”的组件

如果说不必要的重渲染是 React 应用的“慢性病”，那么内存泄漏就是潜伏在暗处的“急性杀手”。它不会立刻让你的页面卡死，但它会让你的应用像一个不断膨胀的气球，最终在某个不经意的时刻——比如用户连续操作半小时后——突然崩溃，控制台里赫然出现Out of memory的错误。而这个错误，往往和mysqld或其他后台进程无关，它就发生在你的 React 组件里。

3.1 泄漏的根源：闭包与生命周期的错位

内存泄漏的本质，是本该被垃圾回收器（GC）清理的对象，因为被意外地持有引用而无法释放。在 React 中，最常见的泄漏场景，就是异步操作与组件卸载的竞态关系。

想象一个典型的“搜索建议”组件：

// ❌ 经典泄漏：组件卸载后，setState 依然在执行 function SearchBox() { const [query, setQuery] = useState(''); const [suggestions, setSuggestions] = useState([]); useEffect(() => { if (query.length < 2) return; // 发起一个防抖后的 API 请求 const timer = setTimeout(async () => { try { const data = await fetchSuggestions(query); // ⚠️ 危险！如果用户在请求返回前就离开了这个页面， // 此时 SearchBox 组件已经 unmount，但 setSuggestions 仍会执行 setSuggestions(data); } catch (error) { console.error(error); } }, 300); return () => clearTimeout(timer); }, [query]); return ( <div> <input value={query} onChange={e => setQuery(e.target.value)} /> <ul>{suggestions.map(s => <li key={s.id}>{s.text}</li>)}</ul> </div> ); }

这段代码看起来天衣无缝：useEffect的清理函数会清除定时器，fetchSuggestions的try/catch也处理了错误。但问题出在setSuggestions(data)这一行。当用户快速输入并迅速导航到其他页面时，SearchBox组件会立即被卸载（unmount）。然而，那个setTimeout里的异步回调，以及后续的fetch请求，依然在后台运行。当请求终于返回，setSuggestions被调用时，React 会发现它试图更新一个已经不存在的组件的状态。虽然 React 18+ 对此做了静默处理（不再抛出警告），但data本身以及它所携带的所有引用，都会因为这个悬空的setState调用而被保留在内存中，无法被 GC 回收。

3.2 解决方案：用AbortController切断连接

现代浏览器提供了一个完美的解决方案：AbortController。它允许你为一个fetch请求创建一个“取消信号”，并在组件卸载时主动中断请求。

// ✅ 安全的写法：用 AbortController 主动取消请求 function SearchBox() { const [query, setQuery] = useState(''); const [suggestions, setSuggestions] = useState([]); useEffect(() => { if (query.length < 2) return; const controller = new AbortController(); const fetchAndSet = async () => { try { // 将 signal 传入 fetch const response = await fetch(`/api/suggestions?q=${query}`, { signal: controller.signal }); const data = await response.json(); // ✅ 只有在组件仍然挂载时才更新状态 if (!controller.signal.aborted) { setSuggestions(data); } } catch (error) { // 如果是 abort 错误，直接忽略 if (error.name !== 'AbortError') { console.error(error); } } }; const timer = setTimeout(fetchAndSet, 300); return () => { clearTimeout(timer); controller.abort(); // 👈 关键！主动取消请求 }; }, [query]); return ( <div> <input value={query} onChange={e => setQuery(e.target.value)} /> <ul>{suggestions.map(s => <li key={s.id}>{s.text}</li>)}</ul> </div> ); }

AbortController的强大之处在于，它不仅能在fetch中使用，还能用于XMLHttpRequest、Streams API，甚至可以被自定义的 Promise 工具函数所消费。它把“取消”这个动作，从一个被动的、不可控的等待，变成了一个主动的、可编程的指令。

3.3 更隐蔽的泄漏：事件监听器与定时器

除了网络请求，事件监听器和定时器也是内存泄漏的重灾区。尤其是在使用第三方库（如地图 SDK、图表库）时，它们常常会要求你手动添加和移除事件监听器。

// ❌ 危险：忘记移除全局事件监听器 function ChartComponent() { useEffect(() => { const handleResize = () => { // 更新图表尺寸 resizeChart(); }; window.addEventListener('resize', handleResize); // ❌ 忘记了 cleanup！ }, []); return <div ref={chartRef} />; }

这个useEffect没有返回任何清理函数，handleResize回调会一直挂在window上，即使ChartComponent已经卸载。随着用户在应用中反复导航，这样的监听器会越积越多，最终拖垮整个页面。

提示：一个简单但有效的自查方法是，在 Chrome DevTools 的Memory面板中，录制一次“Allocation instrumentation on timeline”，然后进行一系列页面跳转操作。结束后，查看“Constructor”列，如果Window、Document或你自定义的类名下面，# Allocations数量持续增长，那基本可以确定存在泄漏。

4. 代码体积的“减法艺术”：从React.lazy到Suspense的渐进式加载

当你的 React 应用从一个简单的 Todo List，成长为一个拥有数十个路由、上百个组件、集成了多个第三方 SDK 的庞然大物时，“首屏加载时间”（First Contentful Paint, FCP）和“可交互时间”（Time to Interactive, TTI）就会成为用户体验的生死线。用户不会关心你用了多么炫酷的技术栈，他们只会在白屏超过 3 秒后，毫不犹豫地关闭标签页。此时，“代码分割”（Code Splitting）就不再是锦上添花，而是雪中送炭。

4.1React.lazy：动态导入的语法糖

React.lazy的本质，就是将 ES6 的import()动态导入语法，封装成一个 React 组件。它让你可以声明式地告诉 React：“这个组件，我不需要在应用启动时就加载它，等我真正需要渲染它的时候，你再去加载。”

// ❌ 传统方式：所有组件在打包时就被静态导入 import Dashboard from './components/Dashboard'; import Reports from './components/Reports'; import Settings from './components/Settings'; function App() { return ( <Router> <Switch> <Route path="/dashboard" component={Dashboard} /> <Route path="/reports" component={Reports} /> <Route path="/settings" component={Settings} /> </Switch> </Router> ); }

上面的代码，无论用户访问哪个路由，Dashboard、Reports、Settings三个组件的代码都会被打包进同一个main.js文件里，随首屏一起下载。这对于一个只访问/dashboard的用户来说，是巨大的浪费。

// ✅ 使用 React.lazy：按需加载 const Dashboard = React.lazy(() => import('./components/Dashboard')); const Reports = React.lazy(() => import('./components/Reports')); const Settings = React.lazy(() => import('./components/Settings')); function App() { return ( <Router> <Suspense fallback={<div>Loading...</div>}> <Switch> <Route path="/dashboard" component={Dashboard} /> <Route path="/reports" component={Reports} /> <Route path="/settings" component={Settings} /> </Switch> </Suspense> </Router> ); }

现在，Dashboard、Reports、Settings的代码会被 Webpack/Vite 自动拆分成独立的 chunk 文件（如123.chunk.js,456.chunk.js）。只有当用户导航到/dashboard时，123.chunk.js才会被浏览器发起请求并下载。这极大地减少了首屏的 JS 体积。

4.2Suspense：优雅降级的“加载状态管理器”

React.lazy只负责“加载”，而Suspense则负责“加载期间的用户体验”。它是一个特殊的 React 组件，其唯一的作用，就是在它包裹的子树中，有任何一个lazy组件正在异步加载时，渲染其fallback属性指定的内容。

fallback的内容可以非常简单，比如一个<div>Loading...</div>，也可以是一个精心设计的骨架屏（Skeleton Screen），甚至是另一个轻量级的、已经加载好的组件。关键在于，Suspense让你能够以一种声明式、非侵入式的方式，统一管理整个应用的加载状态，而无需在每个lazy组件内部去写一堆if (loading) return ...的样板代码。

4.3 实战技巧：Suspense的层级与边界

Suspense的使用位置，是一门需要经验的艺术。一个常见的误区，是把它放在离lazy组件太近的地方，比如：

// ❌ 不推荐：Suspense 太靠近 lazy 组件，粒度过细 function UserProfile() { const Avatar = React.lazy(() => import('./Avatar')); const Bio = React.lazy(() => import('./Bio')); return ( <div> <Suspense fallback={<Spinner size="small" />}> <Avatar /> </Suspense> <Suspense fallback={<Spinner size="small" />}> <Bio /> </Suspense> </div> ); }

这种写法会导致两个问题：一是Avatar和Bio的加载是串行的，Bio必须等Avatar加载完才能开始；二是Suspense的fallback会频繁闪烁，影响体验。

更好的做法，是将Suspense提升到一个更合理的层级，让它包裹一组逻辑上相关的lazy组件：

// ✅ 推荐：Suspense 包裹整个“用户信息”区域 function UserProfile() { const Avatar = React.lazy(() => import('./Avatar')); const Bio = React.lazy(() => import('./Bio')); return ( <div> <Suspense fallback={<UserProfileSkeleton />}> <Avatar /> <Bio /> </Suspense> </div> ); }

这样，Avatar和Bio的加载是并行的，UserProfileSkeleton作为一个整体的加载占位符，也比两个小Spinner更加协调和专业。

注意：Suspense只对React.lazy组件有效。它对fetch请求、setTimeout等原生异步操作是无效的。如果你想对这些操作也实现类似的效果，需要借助useTransition（React 18+）或自定义的Suspense兼容 Hook。

5. 状态与计算的“意图对齐”：useMemo与useCallback的精准狙击

在 React 的世界里，“状态”（State）和“计算”（Computation）是两个截然不同的概念，但它们常常被混为一谈。useState管理的是组件的“记忆”，而useMemo和useCallback管理的则是组件的“意图”。理解这一点，是避免滥用这两个 Hook 的关键。

5.1useMemo：缓存“昂贵的计算”，而非“昂贵的数据”

useMemo的签名是useMemo(() => computeValue(), [deps])。它的核心价值，在于避免在每次 render 时都重复执行一个计算成本高昂的函数。一个经典的例子是“过滤并排序一个大型数组”：

// ✅ 正确：useMemo 用于缓存计算结果 function ProductList({ products, filterText, sortOrder }) { const filteredAndSortedProducts = useMemo(() => { console.log('执行了昂贵的过滤和排序！'); // 仅在依赖项变化时执行 return products .filter(p => p.name.toLowerCase().includes(filterText.toLowerCase())) .sort((a, b) => { if (sortOrder === 'asc') return a.price - b.price; return b.price - a.price; }); }, [products, filterText, sortOrder]); // 依赖项数组 return ( <ul> {filteredAndSortedProducts.map(p => ( <li key={p.id}>{p.name} - ${p.price}</li> ))} </ul> ); }

在这个例子中，products数组可能有上千个元素，filter和sort是 O(n log n) 的操作。如果没有useMemo，每次ProductList组件 re-render（比如父组件传入了一个新的themeprop），这个昂贵的计算都会被执行一遍，造成巨大的性能浪费。

但请注意，useMemo绝不应该被用来“缓存”一个简单的对象或数组字面量：

// ❌ 危险：useMemo 用于缓存简单对象，得不偿失 function BadExample() { // 这个对象创建成本极低，useMemo 的开销（闭包创建、依赖比较）反而更高 const config = useMemo(() => ({ apiEndpoint: '/api/data', timeout: 5000 }), []); return <DataFetcher config={config} />; }

5.2useCallback：缓存“函数的引用”，而非“函数的逻辑”

useCallback的签名是useCallback(() => doSomething(), [deps])。它的核心价值，在于确保函数的引用在依赖项不变的情况下保持稳定。这主要是为了满足React.memo或useEffect的依赖数组要求。

// ✅ 正确：useCallback 用于稳定函数引用，配合 memo function Parent() { const [count, setCount] = useState(0); // ✅ 用 useCallback 包裹，确保 onClick 的引用稳定 const handleClick = useCallback(() => { setCount(c => c + 1); }, []); // 依赖项为空数组，意味着这个函数在整个组件生命周期内都不会变 return <Child onClick={handleClick} />; } const Child = React.memo(({ onClick }) => { console.log('Child render'); return <button onClick={onClick}>Count: {count}</button>; });

如果没有useCallback，Parent每次 re-render 都会创建一个新的handleClick函数，导致Child的props.onClick引用总是变化，React.memo就失去了意义。

5.3 一个反直觉的真相：useCallback并不总是“优化”

这是一个很多资深开发者都会踩的坑。useCallback本身是有成本的。它需要创建一个闭包，需要在每次 render 时比较依赖项数组，需要在内存中存储这个函数的引用。如果一个函数本身非常简单（比如() => console.log('hello')），并且它所接收的props本身就很稳定，那么useCallback的开销，很可能超过了它带来的收益。

因此，我的团队内部有一条不成文的规则：只有当一个函数被传递给一个React.memo组件，或者被用作useEffect的依赖项，并且这个函数的创建成本（或其导致的下游组件重渲染成本）显著高于useCallback本身的开销时，才使用它。对于大多数内部使用的、不对外暴露的事件处理器，我们更倾向于直接在 JSX 中内联编写，因为 React 的 V8 引擎对此有极佳的优化。

提示：V8 引擎会对内联函数进行“逃逸分析”（Escape Analysis）。如果它发现一个内联函数从未被传递给外部作用域（比如没有被addEventListener或setTimeout捕获），它就会将其优化为一个轻量级的、几乎零开销的“快路径”调用。所以，不要想当然地认为“内联函数一定慢”。

6. 性能优化的终点：建立你的“性能基线”与“监控闭环”

性能优化绝非一劳永逸的“一次性工程”，而是一个需要持续投入、闭环管理的“产品化过程”。我见过太多团队，在项目上线前轰轰烈烈地搞了一轮“性能攻坚”，然后就把所有优化手段束之高阁，直到下一个大版本发布时，才发现之前修复的瓶颈又卷土重来，甚至出现了更多新的、更棘手的问题。

6.1 定义你的“性能基线”

在项目启动之初，就应该为关键指标设定一个清晰、可量化的“性能基线”（Performance Baseline）。这个基线不是拍脑袋定的，而是基于真实用户设备和网络环境的测量结果。我们通常会使用 Lighthouse（在模拟的 3G 网络和 Moto G4 设备上）和 WebPageTest（在真实全球节点上）来获取以下核心数据：

这个基线会成为你所有性能工作的“北极星”。每一次代码提交、每一个新功能上线、每一次第三方库升级，你都要用相同的工具、在相同的环境下，重新跑一遍测试，看看这些数字是变好了，还是变坏了。

6.2 构建“监控-告警-归因”闭环

仅仅有基线还不够，你需要一个自动化的监控系统，将性能数据变成可行动的洞察。

1. 监控（Monitoring）：在生产环境中，利用web-vitals库，收集真实用户的LCP、FID、CLS等核心 Web Vitals 指标，并上报到你的 APM（Application Performance Monitoring）系统，如 Sentry、Datadog 或自建的 Prometheus + Grafana。

2. 告警（Alerting）：为关键指标设置阈值告警。例如，当LCP的 P75 分位数超过 2.5s，或者CLS的 P90 分位数超过 0.25 时，自动在 Slack 频道中发送告警，并关联到具体的 Git Commit 和 Release 版本。

3. 归因（Attribution）：这是最难也最关键的一环。当告警响起时，你不能只看到“性能变差了”，你必须能快速定位到“是哪个组件、哪段代码、哪个依赖库导致的”。为此，我们强制要求：

   • 所有React.memo组件都必须添加displayName，方便在 React DevTools 中识别。
   • 所有useEffect和useMemo的依赖数组，都必须是显式的、可读的变量名，禁止使用...rest展开或复杂的表达式。
   • 在 CI 流水线中，集成source-map-explorer，每次构建后自动生成代码体积报告，并与上一个版本进行对比，突出显示体积增长最多的模块。

6.3 最后一个，也是最重要的心得

在我过去十年的前端生涯中，最深刻的体会是：最好的性能优化，往往发生在编码之前，而不是编码之后。它体现在你对技术选型的审慎，体现在你对架构设计的远见，体现在你对“最小可行方案”（MVP）的敬畏。

一个典型的例子是，我们曾为一个数据看板项目评估过两个图表库：一个是功能极其丰富、API 极其复杂的商业库，另一个是轻量、专注、API 极其简洁的开源库。前者能画出更炫酷的 3D 图表，但它的包体积是后者的 5 倍，初始化时间是后者的 3 倍。我们最终选择了后者，因为我们的业务需求，只需要一个清晰、准确、响应迅速的二维折线图。这个选择，省去了后期无数个小时的memo、useCallback和lazy的“打补丁”工作。

所以，当你下次看到一个“5 Tips to Improve the Performance of Your React Apps”这样的标题时，请不要急着去复制粘贴代码。先停下来，问问自己：我的应用，真的需要这 5 个 Tip 吗？还是说，我真正需要的，是一张更早、更清晰、更诚实的“性能诊断地图”，来指引我做出那些真正影响深远的、关于“做什么”和“不做什么”的决策？