React 重渲染优化：拆分组合 Hook 计算（Split Combined Hook Computations）——ZCode 前端性能最佳实践深度解析

导读

本文围绕 ZCode 仓库内置的 React/Next.js 性能优化规范中一条重要的 re-render（重渲染）规则展开：当一个 Hook（如 useMemo、useEffect）内部包含多个相互独立、依赖各异的计算任务时，应将其拆分为多个独立的 Hook，避免"一个依赖变化触发所有任务重算"的依赖放大问题。读完本文，你将掌握如何识别组合 Hook 中的过度计算、如何用拆分式 useMemo 与 useEffect 重构既有代码，以及如何在拆分收益与拆分成本之间做出正确取舍。

规则速览：它在整个优化体系中的位置

该规则完整定义位于 .agents/skills/react-best-practices/rules/rerender-split-combined-hooks.md，文件头部的元数据给出了它的基本画像：

元数据字段	值
title	Split Combined Hook Computations（拆分组合 Hook 计算）
impact	MEDIUM（中等级别影响）
impactDescription	avoids recomputing independent steps（避免重复计算相互独立的步骤）
tags	rerender, useMemo, useEffect, dependencies, optimization

在 SKILL.md 定义的 8 大规则分类中，它隶属于第 5 类 Re-render Optimization（重渲染优化），与 rerender-memo、rerender-dependencies、rerender-derived-state 等 15 条规则同属一组，文件前缀统一为 rerender-。该分类的总体目标是"减少不必要的重渲染，最小化浪费的计算，提升 UI 响应性"。本规则聚焦的是其中最容易遗漏的一类浪费：Hook 内部的重复计算。在综合参考文档 AGENTS.md 中，它被编排为第 5.9 节（位于 L1926-L1984）。

问题本质：组合 Hook 的"依赖放大"效应

先看规则的核心论断：

当一个 Hook 包含多个相互独立、依赖各异的任务时，应把它们拆分为多个独立的 Hook。组合在一起的 Hook 会在任何一个依赖发生变化时重跑全部任务，即使其中某些任务根本用不到这个变化的值。

这是 React 依赖数组（dependency array）的固有语义：useMemo 和 useEffect 都以"浅比较依赖数组"的方式决定是否重新执行。只要数组中任意一个元素在两次渲染之间发生了变化，Hook 就会整体重新执行一次。于是，把两个任务写进同一个 Hook，就相当于强制它们共享同一组依赖——任务的依赖集合变成了并集，这被称为"依赖放大"。

假设任务 A 只依赖 a，任务 B 只依赖 b，合并成一个 Hook 后，依赖变为 [a, b]：

• 修改 a → 整个 Hook 重跑，任务 B（本不需要重跑）也跟着重跑；
• 修改 b → 整个 Hook 重跑，任务 A（本不需要重跑）也跟着重跑。

每次多跑的都是无用功。当这些任务的计算成本较高（如遍历大数组、复杂排序、网络日志上报）时，这种浪费会在高频交互场景下被显著放大。

useMemo 拆分实战：过滤 + 排序的经典案例

错误写法：一次 useMemo 串起两个独立步骤

规则给出了一个非常典型的电商/列表场景——先按分类过滤商品，再按价格排序：

const sortedProducts = useMemo(() => {
  const filtered = products.filter((p) => p.category === category);
  const sorted = filtered.toSorted((a, b) =>
    sortOrder === "asc" ? a.price - b.price : b.price - a.price,
  );
  return sorted;
}, [products, category, sortOrder]);

这段代码的问题在于：排序任务本不依赖 category，过滤任务本不依赖 sortOrder，但两者被强行绑进同一个 useMemo，依赖数组不得不写成三者的并集 [products, category, sortOrder]。结果就是：

• 用户切换排序方式（sortOrder 变化）→ 过滤任务被白白重跑一遍；
• 用户切换分类（category 变化）→ 排序任务被白白重跑一遍；
• 完整流程从"过滤（遍历一遍数组，O(n)）"到"排序（O(n log n)）"全部重算。

随着商品列表规模增长，这种"白跑"的累积成本会越来越明显。

正确写法：拆成两个各自独立的 useMemo

const filteredProducts = useMemo(
  () => products.filter((p) => p.category === category),
  [products, category],
);

const sortedProducts = useMemo(
  () =>
    filteredProducts.toSorted((a, b) =>
      sortOrder === "asc" ? a.price - b.price : b.price - a.price,
    ),
  [filteredProducts, sortOrder],
);

拆分后，两个任务的依赖回归各自的最小集合：

• 过滤任务只在 products 或 category 变化时重跑；
• 排序任务只在 filteredProducts（过滤结果）或 sortOrder 变化时重跑。

于是：切换排序方式时，只重新执行 O(n log n) 的排序；切换分类时，先跑 O(n) 的过滤，再基于新结果跑排序——没有任何一步是无用的。需要注意，第二个 useMemo 的依赖是第一个的输出 filteredProducts 而非原始 products，这构成了一个天然的"派生管线"：第二级只在自己真正的输入变化时才失效，这正是拆分能成立的关键。

底层原理：memo 缓存命中与失效传播

从 React 的实现语义看，useMemo(factory, deps) 返回的缓存值只有在 deps 发生浅比较变化时才失效并重算。拆分方案下：

1. 第一级 filteredProducts 引用在 [products, category] 未变时保持稳定；
2. 第二级的依赖 filteredProducts 因此保持引用相等，sortOrder 未变时第二级直接命中缓存，不重算。

引用稳定性（reference stability）是串联派生计算时的核心杠杆——这也与同一分类下 rerender-dependencies.md 中"收窄依赖到原始值/最小粒度"的思想一脉相承：依赖越窄，缓存命中的概率越高，重算范围越小。

useEffect 拆分实战：无关副作用的分离

useMemo 之外，同一模式对 useEffect 同样适用。规则原文强调："该模式同样适用于组合了无关副作用的 useEffect"。

错误写法：两个副作用共享依赖数组

useEffect(() => {
  analytics.trackPageView(pathname);
  document.title = `${pageTitle} | My App`;
}, [pathname, pageTitle]);

页面埋点上报依赖的是 pathname（路由路径），设置文档标题依赖的是 pageTitle。两者合并在同一个 effect 里，依赖数组被迫写成 [pathname, pageTitle] 的并集：

• 标题变化但路由没变 → 埋点被重复上报（在统计场景里还可能造成数据污染）；
• 路由变化但标题没变 → 标题被重复设置。

正确写法：两个 effect 各自独立运行

useEffect(() => {
  analytics.trackPageView(pathname);
}, [pathname]);

useEffect(() => {
  document.title = `${pageTitle} | My App`;
}, [pageTitle]);

拆分之后，两个副作用只在各自真正关心的输入变化时执行一次，互不干扰。这里还涉及 useEffect 的另一层成本：effect 每次重跑可能伴随清理函数（cleanup）先执行、新副作用再执行的完整生命周期，合并写法会让与当前变化无关的副作用也反复经历"清理—重建"循环（如重复订阅/退订、重复上报），其成本往往比 useMemo 的重算更隐蔽。

拆分决策指南：何时拆、何时不拆

拆分并非无脑行为，判断标准可以归纳为三问：

判定问题	答案	结论
任务之间是否相互独立？	是（A 的结果不喂给 B，或 B 只消费 A 的稳定输出）	倾向拆分
任务依赖集合是否差异明显？	是（如 [a] 与 [b]，交集很小）	倾向拆分
单个任务的计算成本是否值得缓存？	是（遍历、排序、网络上报、DOM 写入等）	倾向拆分

反之，若出现以下情况则不建议拆分：

• 计算成本极低：一个简单的表达式/原始值计算不应放进 useMemo（参见同分类规则 rerender-simple-expression-in-memo.md），拆分自然也无必要；
• 所有任务共享完全相同的依赖：此时合并与拆分的重算行为完全一致，拆分只会多引入一个 Hook 的管理成本；
• 任务间存在强耦合的中间状态：如第二步必须消费第一步的完整输出且与第一步共享所有依赖，强行拆分反而引入额外的引用稳定性负担。

此外，useMemo 本身不是免费的：每多一个 useMemo 就多一份依赖数组的浅比较开销和内存占用。规则定位为 MEDIUM 影响，即"值得做但不必过度"，正确的姿态是优先拆分计算密集的组合 Hook，而非逐行打磨微小的派生表达式。

关联规则矩阵：与其他 rerender 规则的协同

拆分组合 Hook 往往需要与其他重渲染优化规则配合使用，形成一套完整的优化动作：

关联规则	文件	与本规则的协同点
收窄 effect 依赖（Narrow Effect Dependencies）	rerender-dependencies.md	拆分后继续把对象依赖收窄为原始值依赖，进一步减少重跑；派生布尔值应在渲染期计算而非放进 effect
提取为 memo 组件（Extract to Memoized Components）	rerender-memo.md	当拆分出的任务本身较重且可独立渲染时，进一步将其提取为 memo() 包裹的子组件，配合 useMemo 双重缓存
订阅派生状态（Subscribe to Derived State）	rerender-derived-state.md	过滤/排序的中间产物本质上就是派生状态，保持其引用稳定可以让下游订阅（如子组件 props）受益

实际重构中的推荐顺序是：先按本规则把组合 Hook 拆开，再按 rerender-dependencies.md 收窄每个 Hook 的依赖粒度，最后视情况用 memo() 切断子组件链路。

仓库中的实际应用场景

从源码结构看，ZCode 的 UI 层（packages/ui/src）中大量组件同时使用了 useMemo、useCallback、useEffect、useRef、useState 等多类 Hook，这正是本规则的适用土壤。例如 GitPane.tsx（第 2 行）同时导入这五个 Hook，且该组件集中承载来源切换、diff 懒加载、展开状态与文件变更查找联动等多路状态与计算，其中"基于变更列表的过滤/查找结果"与"diff 内容的懒加载缓存"等派生逻辑天然具备不同的依赖集合，是拆分组合计算模式的高价值落点。同样，ToolCallBlocks 目录下多个渲染器对编辑 diff、工作流片段等数据做了 useMemo 派生，任何新增的、与既有 memo 共享依赖数组却语义独立的计算，都应当被识别为潜在的拆分对象。

说明：以上仅为代码结构层面的场景推断，用于帮助读者在阅读源码时定位规则的适用位置；具体的拆分动作应以实际数据规模和变更频率为准。

关于 React Compiler 的补充说明

规则末尾有一条重要的附注，需完整继承：

注意： 如果你的项目启用了 React Compiler，它会自动优化依赖追踪，上述部分场景可能已被它自动处理。

React Compiler 能在编译期分析组件与 Hook 的依赖关系，自动插入等价于 useMemo/useCallback 的记忆化逻辑，因此对于已启用 Compiler 的项目，手动拆分组合 Hook 的收益可能被自动优化部分覆盖。但需要强调的是：依赖放大问题的本质（无关任务被错误地共享依赖）并不能被单纯记忆化完全消除，拆分依然能在语义层面让依赖关系更清晰、更利于后续维护与自动化代码审查。ZCode 的这套规范以 Markdown 规则文件形式沉淀在仓库中，其设计初衷正是为 AI Agent 与 LLM 在编写、评审、重构 React/Next.js 代码时提供可检索、可执行的判定依据（参见 AGENTS.md 开头对文档用途的说明），因此无论是否启用 Compiler，遵循本规则都能让产出代码的可读性与可分析性更好。

自查清单

在代码评审或重构时，可对照以下清单快速检查是否命中本规则：

• [ ] 是否存在一个 useMemo/useEffect 的依赖数组中混入了与其中部分任务无关的依赖？
• [ ] 修改任一依赖时，是否导致 Hook 中某些根本不受影响的任务被重跑？
• [ ] 两个任务的依赖集合交集是否明显小于并集，且任务本身计算成本可观？
• [ ] 拆分后每个 Hook 的依赖是否已收窄到最小粒度（配合 rerender-dependencies 规则）？
• [ ] 拆分是否引入了不必要的额外 useMemo（任务本身极廉价或依赖完全相同）？

遵循"组合 Hook 按依赖边界拆分"这一原则，配合依赖收窄与 memo 组件提取，可以让 React 应用的每一次状态变更都精确命中需要重算的路径，把浪费的重渲染与重复副作用从高频路径上移除。