React 性能问题通常始于状态，而不是渲染

Source: Dev.to

为什么状态设计是性能问题的根源

当 React 应用开始变慢时，直觉往往是去使用优化工具——记忆化、useCallback、useMemo 以及性能分析会话。虽然这些工具很有价值，但它们很少是问题的真正起点。大多数 React 性能问题源自 状态设计，而不是渲染本身。

React 对重新渲染非常擅长；渲染是廉价的。真正昂贵的是 触发重新渲染的原因 和 受影响的树的范围。当状态被提升得太高、耦合过紧或间接被修改时，微小的变化会波及应用的大块区域。

常见的“味道”

全局或顶层状态

一个常见的症状是全局或顶层状态频繁变化。当许多组件依赖同一块状态时，React 被迫重新评估大量子树，即使大多数组件并不真正关心这次变化。看起来像是渲染问题，实质上是 数据所有权问题。

过早的优化

过早地加入记忆化往往会增加复杂度，却没有解决根本原因。它会引入依赖管理、陈旧值以及认知负担——所有这些只是为了弥补不清晰的状态边界。

状态所有权的最佳实践

• 让状态靠近使用它的地方。 状态应尽可能靠近读取或写入它的组件。
• 在本地派生数据，而不是全局存储。把派生值的计算放在需要它们的组件内部。
• 允许自由的重新渲染。 当组件拥有独立且廉价的渲染时，重新渲染的成本几乎可以忽略不计。

有益的思维转变

不要问 “我该如何阻止这个组件重新渲染？”，而要问 “为什么这个状态的变化会影响到这么多应用？”。答案通常直接指向解决方案：重构状态，使只有真正需要它的组件订阅它的变化。

架构层面的关注点

React 性能在很大程度上是一个架构问题。把状态所有权和数据流做好，渲染往往会自我调节。