标签：React 第11页

体积优化的顺序是「先量（parsed size，不是 gzip）、再砍（tree-shaking / 依赖替换 / 去重）、然后拆（代码分割）、最后压（terser + brotli）」，并用「体积预算 + CI 门禁」把结论固化下来，防止悄悄回涨。

赞(0)陌上寒2026-10-1505-性能优化 阅读()去评论

前端内存泄漏的本质是「本该被回收的对象，仍然被某个『活着的引用』链到 GC 根」——排查方法不是「看内存涨没涨」，而是「操作并回退后 GC，看对象是否回落」，工具是「三快照对比 + Allocation timeline + queryObjects + Detached elements」。

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论

Profiler 的价值是「把『这次交互渲染了哪些组件、各花了多久、为什么渲染』量出来」——它有三个视图（火焰图 / 排名 / 时间线）与两个编程式 API（），关键概念是「actualDuration vs baseDuration」，后者能直接告诉你「记忆化…

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论

RUM（Real User Monitoring） 的核心不是「装个库」，而是「采集真实用户的 Core Web Vitals + 把每个指标归因到具体元素/交互 + 用分位数而不是平均值观察」——只有归因，指标才能变成可执行的优化项。

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论

React Compiler 是「编译时自动记忆化」的工具——它在构建阶段分析组件并自动插入缓存（相当于替你写 useMemo/useCallback/memo），让日常代码可以写得更「朴素」，但它依赖「组件是纯函数」的假设，且不能替代对渲染机制的理解。

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论

Context 的订阅粒度是整个 value——value 一变，所有消费者都重渲染（React.memo 拦不住）；优化方案按成本排序是「useMemo 稳定 value → 拆分 Context → 值与操作分离 → children 透传 → 状态库选择器」。

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论

引用不稳定是 React 性能问题最常见的根源——「每次渲染都新建的对象/数组/函数」会让 memo 失效、让 useEffect 反复执行、让缓存失去意义；解法是「提到模块外 → useMemo/useCallback → 依赖原始值 → 用 ref → data- + 事件委托」。

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论

useTransition / useDeferredValue 不减少工作量——它们改变的是「优先级」，让「昂贵但不紧急的更新」不阻塞「紧急交互（如输入回显）」，从而改善可交互性（INP）。

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论

代码分割（Code Splitting）用「动态 import()」把 bundle 拆成多个 chunk，按路由或按组件的交互时机加载——这是改善首屏加载最有效的手段之一。

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论

长列表的性能瓶颈有三层——React 渲染（几千个组件函数）、DOM 数量（几千个节点）、布局与绘制；对应手段是「稳定 key + 行组件 memo + 稳定处理函数 + 虚拟滚动 + 避免渲染中重算」。

赞(0)陌上寒2026-10-1405-性能优化 阅读()去评论