23.2 浏览器性能面板：定位长任务与卡顿

在 React 应用中，状态管理的好坏直接决定了代码的可维护性、可测试性和性能。很多常见的 bug——比如组件不更新、不必要的重渲染、状态同步错乱——根源都在于状态设计不合理。

本节总结三条核心的状态管理原则，它们相互关联、层层递进，能帮你构建清晰可靠的数据流。

状态最小化：只存必要的数据

原则：组件状态中只保存“必须且无法通过计算得到”的数据。任何可以从现有状态或 Props 推导出来的值，都不应该单独存一份状态。

为什么重要：每增加一个冗余状态，就多了一处需要维护的数据，也多了一份数据不一致的风险。

常见反例与修正：

❌ 错误做法——同时维护原始数据和过滤结果：

function ProductList({ products }) {
  const [keyword, setKeyword] = useState('');
  const [filteredProducts, setFilteredProducts] = useState(products);

  // 需要手动在两个地方同步逻辑
  function handleSearch(text) {
    setKeyword(text);
    setFilteredProducts(
      products.filter(p => p.name.includes(text))
    );
  }
}

问题在于 filteredProducts 其实完全可以从 products 和 keyword 计算得出，额外维护它只会增加同步负担和出错概率。

✅ 正确做法——只存最小状态，其余通过计算得出：

function ProductList({ products }) {
  const [keyword, setKeyword] = useState('');

  // 直接计算，不额外维护状态
  const filteredProducts = products.filter(p =>
    p.name.includes(keyword)
  );

  return (
    <>
      <input onChange={e => setKeyword(e.target.value)} />
      {filteredProducts.map(p => <Item key={p.id} product={p} />)}
    </>
  );
}

keyword 是唯一的可变源头，filteredProducts 自动跟随变化，永无不同步之忧。

实践清单：

检查每个 useState：这个值是否能从别的状态/Props/全局变量计算出来？
能用 useMemo 计算的值，不应该新增状态。
能通过组合现有状态得到的数据，不要去重复存储。

状态提升：把共享状态放到最近的公共祖先

原则：当多个组件需要共享同一份状态时，将该状态“提升”到它们最近的公共父组件中，然后通过 Props 向下传递。这就是“状态提升”（Lifting State Up）。

为什么重要：保证数据单向流动，避免产生多个互相竞争的数据副本。

场景示例：手风琴效果，多个面板只能同时展开一个。

❌ 错误做法——每个面板自己管理展开状态：

function Panel({ title, children }) {
  const [expanded, setExpanded] = useState(false);
  // 每个面板独立维护，无法实现互斥
}

这样永远无法实现“展开一个时关闭其他”，因为它们的状态彼此隔离。

✅ 正确做法——将当前展开的面板 ID 提升到父组件：

function Accordion() {
  const [activeId, setActiveId] = useState(null);

  return (
    <>
      <Panel
        title="面板1"
        isActive={activeId === 1}
        onShow={() => setActiveId(1)}
      >
        内容1
      </Panel>
      <Panel
        title="面板2"
        isActive={activeId === 2}
        onShow={() => setActiveId(2)}
      >
        内容2
      </Panel>
    </>
  );
}

function Panel({ title, children, isActive, onShow }) {
  return (
    <div>
      <h3 onClick={onShow}>{title}</h3>
      {isActive && <div>{children}</div>}
    </div>
  );
}

所有面板的展开状态都来源于同一个 activeId，互斥逻辑自然成立，数据流清晰。

注意：状态提升可能会导致“Props 层层传递”问题（Prop Drilling）。如果共享状态需要经过很深的组件树，可以进一步使用 Context 或状态管理库解决，但基本原则不变——状态的所有权要明确、唯一。

就近原则：状态尽可能靠近使用它的组件

原则：状态应该定义在最靠近使用它的地方，而不是一上来就放到全局或高层级组件中。

为什么重要：

减少不必要的重渲染：如果状态放在根组件，任何变化都会导致整棵树重新渲染；如果放在叶子组件，影响范围最小。
提升封装性：状态和逻辑放在一起，组件更内聚，更容易拆解和复用。
简化维护：阅读代码时，可以立即看到状态的定义和使用场景，不需要跨文件跳转。

实战分析：

设想一个搜索框，其关键词状态应该放在哪里？

❌ 错误做法——放在全局 Store 或根组件：

// 全局状态管理（例如 Redux store）
const keyword = useSelector(state => state.search.keyword);

当 keyword 变化时，所有连接到 Store 的组件都会被告知，即使它们根本不关心搜索关键词。

✅ 正确做法——放在搜索框组件自身：

function SearchBar({ onSearch }) {
  const [keyword, setKeyword] = useState('');

  return (
    <input
      value={keyword}
      onChange={e => setKeyword(e.target.value)}
      onKeyDown={e => e.key === 'Enter' && onSearch(keyword)}
    />
  );
}

这个状态完全属于搜索框，它的变化不会影响其他任何组件。父组件只需要关心搜索的最终结果即可。

平衡“状态提升”与“就近原则”：

如果一个状态只被单一组件使用，就放在该组件内部。
如果它被少量近邻组件使用，提升到它们的直接父组件。
如果被大量远距离组件使用，再考虑 Context 或状态管理库。

这个决策流程能帮你避免“过度提升”导致的冗长 Props 链，也能避免“过早全局化”导致性能问题。

总结：三条原则的协同

状态最小化：决定“存什么”，减少冗余状态。
就近原则：决定“放在哪”，优先放在局部，避免污染全局。
状态提升：解决“共享问题”，当局部不够时，向上升级。

始终遵循：能计算就不存储，能局部就不全局，必须共享时找到唯一的公共祖先。这套思维模式能让你的 React 状态管理既直观又健壮。