React 渲染性能排查先确认是谁在重复渲染一、性能问题不要先猜优化点React 页面卡顿时很多人第一反应是加memo、加useMemo、拆组件。但如果没有确认是谁在重复渲染这些优化很可能只是心理安慰。性能排查要先看证据哪个组件频繁渲染为什么渲染渲染成本有多高。先定位再优化。React 性能问题尤其怕一边猜一边改。二、从 Profiler 开始flowchart TD A[页面卡顿] -- B[Profiler] B -- C[重复渲染组件] C -- D[状态来源] D -- E[优化边界]React DevTools Profiler 可以看到 commit 时间、组件渲染次数和耗时。先记录一个用户操作流程再分析热点组件。const ProductCard React.memo(function ProductCard({ item }) { return div{item.title}/div; });memo要建立在 props 稳定的前提上否则每次传入新对象还是会渲染。Profiler 录制时有一点常被忽略录制环境本身也会影响性能数据。React DevTools 的 Profiler 在生产模式下不可用而开发模式下的渲染开销本身比生产大。更准确的对比是在同一分支、同一模式、同一设备上录制前后两个版本只看相对变化而不是绝对数字。三、状态边界很关键全局状态变化会带动大量组件更新。不是所有状态都应该放进全局 Store也不是所有页面都要订阅完整对象。const title useProductStore(state state.product.title);选择更小的状态片段可以减少无关渲染。列表页面尤其要注意筛选条件、弹窗状态、输入框值不要轻易影响整棵列表。四、引用稳定不是万能药useCallback和useMemo可以稳定引用但它们也有成本。只有当引用不稳定导致子组件重复渲染或者计算确实昂贵时再使用更合理。const handleSelect useCallback((id: string) { setSelectedId(id); }, []);还要检查 key。列表 key 不稳定会导致组件重建输入状态、动画状态和缓存都可能丢失。最后性能优化要回归用户路径。开发环境下的小卡顿未必影响用户低端设备上的长列表卡顿才更值得优先处理。还要关注 Context。一个 Provider 的 value 每次 render 都生成新对象下面所有消费者都可能跟着更新。可以把 value 拆小或者用 memo 保持引用稳定。const value useMemo(() ({ theme, setTheme }), [theme]); return ThemeContext.Provider value{value}{children}/ThemeContext.Provider;事件处理也会带来隐性成本。父组件每次创建新回调子组件即使用了 memo 也可能失效。是否需要useCallback要结合子组件是否 memo、回调是否作为依赖传入来判断。最后优化后要再次录制 Profiler。看到 commit 时间下降、渲染次数减少才能说明优化有效。否则只是把代码变复杂。还要区分渲染慢和请求慢。用户觉得页面慢可能是接口返回慢、图片加载慢、脚本执行慢也可能是 React 渲染慢。Profiler 只能证明渲染部分的问题不能替代网络瀑布图和 Web Vitals。frontend_perf_sources: network: check_waterfall render: check_profiler script: check_long_task layout: check_cls如果页面首屏慢先看 LCP 和资源加载如果交互后卡顿再看组件更新和长任务。排查入口不同优化手段也不同。单次排查解决后还要防止性能回退。可以把 Profiler 录制嵌入 E2E 测试每次代码变更后自动跑一组核心用户路径对比关键组件的渲染次数和 commit 耗时it(列表页筛选不应触发全量重渲染, async ({ page }) { const renderCounts await page.evaluate(() { return window.__REACT_PROFILE__ // 通过 React DevTools backend 收集 }) await page.click([data-testidfilter-status]) await page.click([data-testidoption-active]) const afterCounts await page.evaluate(() window.__REACT_PROFILE__) const diff afterCounts.listItem - renderCounts.listItem expect(diff).toBeLessThanOrEqual(5) // 筛选后最多新增渲染 5 个列表项组件 })这个测试的阈值 5 是经验值实际要根据页面结构和筛选逻辑调整。更重要的是这种测试不能替代人工 Profiler 分析它只负责抓大幅回退——比如某次重构让筛选触发了 200 次额外渲染测试会立刻失败开发者能在合并前修复。五、总结React 渲染性能排查要先用 Profiler 找重复渲染再检查状态边界、props 稳定性、key 和真实用户路径。先确认是谁在重复渲染再决定怎么优化。排查时还有一个经验如果 Profiler 显示某个组件自身渲染很快但被渲染了非常多次优先解决为什么渲染这么多次而不是怎么让它渲染更快。减少无效渲染次数带来的收益通常远大于微优化单次渲染开销。