https://example.pages.dev/tags/%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/性能优化HugoBlox Kit (https://hugoblox.com)zh-HansFri, 22 Nov 2024 00:00:00 +0000https://example.pages.dev/media/icon_hu_da05098ef60dc2e7.pnghttps://example.pages.dev/tags/%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/https://example.pages.dev/blog/react-performance/Fri, 22 Nov 2024 00:00:00 +0000https://example.pages.dev/blog/react-performance/<p>React 项目在体量增长之后，性能问题往往不是单点爆炸，而是很多小问题叠加出来的。真正有效的优化，通常从定位问题开始，而不是盲目加 <code>memo</code> 或者到处缓存。</p> <h2 id="1-先量化再优化">1. 先量化，再优化</h2> <p>在动手之前，先用浏览器性能面板和 React DevTools Profiler 看清楚是哪里慢。常见问题包括不必要的重复渲染、超大列表、昂贵计算、首包过大以及 Context 设计不合理。</p> <h2 id="2-把高频渲染链路找出来">2. 把高频渲染链路找出来</h2> <p>如果父组件频繁更新，而子组件又很多，就很容易造成整片区域一起重渲染。这个时候应先检查状态放置位置是否合理，再决定是否使用 <code>memo</code>、拆分组件或调整数据流。</p> <h2 id="3-区分计算慢还是渲染慢">3. 区分“计算慢”还是“渲染慢”</h2> <p>有些页面卡，是因为筛选、排序、格式化数据太重；有些则是 DOM 节点太多。前者更适合做缓存或预计算，后者更适合做列表虚拟化、分页或懒加载。</p> <h2 id="4-大列表一定要控制渲染量">4. 大列表一定要控制渲染量</h2> <p>当列表长度上千时，一次性渲染全部节点通常是不划算的。无论用虚拟列表还是分段加载，本质都是减少首屏和滚动过程中的真实 DOM 数量。</p> <h2 id="5-包体积优化同样重要">5. 包体积优化同样重要</h2> <p>性能不只是交互速度，还包括首屏加载。对大型页面做按需加载、拆包和资源延迟加载，通常能比微调组件更直接地改善用户感知。</p> <h2 id="结语">结语</h2> <p>React 性能优化最重要的原则是有证据地做决策。先找到瓶颈，再选择最小但有效的改动，通常比“全局优化一遍”更稳，也更不容易引入新的复杂度。</p>