减少 React 的属性钻取问题及“上帝组件”现象
学习七种具体的重构模式，通过隔离状态、数据获取、权限控制和加载逻辑来拆分臃肿的 React 组件，而不仅仅是简单分割文件。
曾有一段时间，React 的复杂度完全通过代码行数来评判。一旦某个组件的行数超过三百行，工具栏就会被拆分到单独的文件中；而当行数达到四百行时，表格也会被提取出来。虽然顶层文件的体积变小了，但该功能的理解难度并未降低。父组件依然要处理所有的网络请求、每个模态框、分散在各处的表单字段及其验证状态、对当前用户操作权限的判断，以及屏幕在加载、编辑、保存甚至出错时所经历的各种状态变化。
实际上发生的情况只是对现有结构的重新排列，并没有改变“房子的归属者”。
这一区别值得我们认真思考，因为仅凭大小并不能判定其优劣。如果某个组件代表的是一个完整且连贯的用户界面部分，那么它体积较大也是合理的。复杂的编辑器、控制面板或报表页面包含大量标记代码同样是合情合理的。问题在于，当某个组件变成了所有毫无关联的决策都在此做出的唯一场所时。
以下这些模式本身并非 React 的缺陷。在规模较小或设计更为精心的项目中，它们都有其合理的应用场景。只有当它们在大体积组件中反复出现时，才会成为负担——因为每次出现都会增加组件间的耦合度，扩大因重新渲染而受影响的范围，并迫使未来的每一次修改都必须同时考虑整个界面。
去除这些冗余元素后，不会留下一堆毫无意义的微小组件，反而能让状态管理、数据获取、交互处理和渲染逻辑的架构更加清晰。由于功能模块之间相互干扰的情况减少了，代码也更容易修改。
1. 将整个功能向下传递的组件
在大型界面中常见的一种做法是，几乎将所有大型对象和冗长的回调函数列表都传递给每个子组件。
想象一下，一个结果表格会接收当前用户信息、完整的权限对象、激活的筛选条件、选中的行数据、加载状态标志、若干个修改函数、模态框设置器以及通知处理函数——此外还有几项它根本不会直接处理的值。该表格会将其中一些数据直接传递给行组件，而这些行组件又会进一步将数据传送到各个单元格和按钮中。
从文件结构来看，所有内容似乎都被清晰地分隔开了。但实际在组件之间流动的数据却揭示了不同的情况：每个子组件实际上仍与整个功能模块紧密相连。
这会引发两个明显的问题。首先，理解难度增加。一个接收十五个属性的组件很难被清晰理解，因为它的实际功能被隐藏在那些本应属于其父组件的细节之中。其次，更改会波及多个层面。仅仅重命名一个权限字段或稍作调整某个操作的函数签名，就意味着需要编辑多层组件，而这些组件原本就并不真正负责处理该功能。
解决方法是用针对每个子组件实际职责而设计的精简接口，取代那些范围宽泛、以功能为导向的属性。表格只需要行数据、选择状态以及类似onRowSelected的回调函数即可。操作菜单则只需包含特定记录对应的操作选项——无需涉及整个权限模型以及所有现有的修改函数。
要实现这一目标，通常需要在渲染之前构建一个小型视图模型或动作模型。这额外的准备步骤很有价值，因为它迫使父组件在传递任何内容之前，先将原始的应用状态转换为更简洁、专为特定功能设计的接口。
关键并非仅仅为了减少属性数量而这么做。真正的优势在于子组件不再需要理解整个页面的运作方式，它们只需知道要显示哪些数据以及需要向上层报告什么信息即可。
一旦每个子组件都承载着父组件全部内部状态的一部分，大型组件就会变得脆弱。而明确、专为特定功能设计的接口则能让UI的各个部分独立发展，而不必在每次交互中都牵涉到整个功能模块。
2. 每次渲染时创建新的对象和函数
每个 React 组件在渲染时都会自然生成新值。你可以将选项对象传递给子组件、过滤数组，或编写内联事件处理函数。大多数情况下，这些操作并不重要。
但在复杂的组件树中，新创建的引用可能会悄无声息地破坏其生成组件下方几层结构的记忆化机制。
以使用 memo 构建的子组件为例：即使该对象内部的字段值从未改变，只要在每次父组件传递时它的标识发生变化，它仍会重新渲染。因为其依赖数组中包含了新生成的配置对象，所以相关的效应函数也会重新执行。此外，当某些完全无关的模态状态发生变化时，表格的列定义会被重新生成，从而导致表格需要重新计算列内容。
这段代码表面上看起来非常稳定，但实际上却隐藏了这个问题：
<ResultsTable
columns={[
{ key: "name", label: "Name" },
{ key: "status", label: "Status" },
]}
options={{
selectable: true,
compact: false,
}}
/>
从 JavaScript 的视角来看，每次渲染时数组及其内部的对象都是全新的。这是否真的会引发问题，完全取决于使用这些数据的地方。
将 useMemo 和 useCallback 作为万能解决方案也是不对的。把所有内容都用记忆化处理只会增加额外的复杂性以及依赖数组带来的麻烦。更好的思路是先思考这些值是否真的需要在渲染时才被生成。
静态配置完全可以移出组件之外。那些偶尔会变化的配置则可以放入专用的钩子函数中。当某个对象的唯一作用就是将几个基本元素组合在一起时，直接传递这些基本元素通常更为简洁。只有当事件处理函数的标识确实重要时——比如用于订阅、记忆化子组件或下游的复杂重新计算——才需要使用 useCallback 来确保其稳定性。
我们追求的绝不是为了纯粹的引用纯度而这样做。在渲染过程中创建小型值是正常现象，且通常无害。只有当引用标识在组件树的其他部分真正起到作用时，才需要格外小心。
在大型组件中，一次微小的状态更新就可能导致父组件重新渲染，并进而生成一大批新的值。如果每个子组件都将变化的引用视为变化的数据，那么一次小小的本地更新就会导致整个页面失效。
3. 移除驱动整个页面的单一查询
大型页面通常从一次请求开始，该请求旨在获取界面可能需要的所有数据。这一次响应会包含汇总指标、表格行、筛选条件、相关记录、权限数据、近期历史记录，甚至是一些用户可能永远不会打开的模态框才需要的字段。
乍看之下，这种方法似乎很高效，因为页面只有一个加载状态和一个明确的数据来源。但它也会让页面的每个部分都依赖于该响应中最慢、最不可靠的那部分数据。
如果历史服务出现故障，主表格可能根本无法显示。庞大的关联数据集会增加初始加载量，即便那些从不打开相关面板的用户也会受到影响。而且由于整个页面共享同一个数据边界，仅刷新某个部分就不得不重新加载整个页面。
更好的方法是使用与屏幕实际显示内容相匹配的数据边界，来替代这种整页范围的请求。首先加载主要内容，次要面板则仅在需要时才获取自己的数据。昂贵的详细信息会在用户打开特定记录时再被检索，而非默认情况下就包含在每一行数据中。
这并不意味着每个简单的组件都要发起一次网络请求。过度采用这种分离方式会带来新的问题——请求呈瀑布式传递、重复调用以及加载状态不一致。真正重要的边界通常是具有独立生命周期且对“失败”有明确定义的模块。
汇总组件和历史审计日志无需作为一个整体来成功或失败。表格与很少使用的编辑面板也不必使用相同的初始数据。一旦将这些部分分开，即使某个可选模块出现故障，页面依然可以正常运行。
由于不再需要模拟那种庞大且复杂的响应结构，该组件本身也变得更容易理解。每个区域都能获得其实际所需的数据格式，缓存失效时也可以仅针对发生变化的记录进行处理，而无需影响整个页面。
当数据模型是出于页面层面的便利性而非组件内各个功能的自然生命周期来设计时，大型组件往往就会变得脆弱。
4. 移除由数十个标志控制的通用组件
为避免代码重复，人们常见的做法是创建高度可配置的组件。一个面板可以被设置为可搜索、可选择、分页显示、可编辑、可导出以及可折叠，而所有这些功能都通过越来越多的布尔属性来控制。
它似乎能适用于多种场景，因此看起来可以重复使用。但实际上，每新增一个界面就意味着要为现有的条件列表再添加一条规则。
<DataPanel
searchable
selectable
showToolbar
allowExport={canExport}
inlineEdit={mode === "admin"}
compact={isInsideModal}
hidePagination={rows.length < 20}
stickyHeader={!isMobile}
/>
真正的问题不仅仅在于属性数量过多。这些标志之间会以难以预测的方式相互影响。一旦进入选择模式，内联编辑的行为也会发生变化。紧凑的布局需要独立的工具栏逻辑。在特定的溢出容器中，固定顶部的元素会出现显示异常。可能的标志组合数量增长速度远远超过人们实际测试它们的能力。
这个组件最终会悄悄变成隐藏在第一个应用中的第二个应用。
放弃基于标志的复用方式意味着应采用更小、可组合的组件，并在差异较大的地方设置明确的独立变体。根据需求，表格可以与工具栏、分页控件以及选择功能结合使用。可编辑表格可以作为一个独立的特性存在，而不只是嵌在通用表格组件中的另一个布尔分支。
当两个界面拥有真正的相同底层结构时，可直接复用该结构。而如果它们在截图上仅外观相似，但实际上遵循不同的工作流程，再强行将它们纳入同一抽象层中就毫无意义了。
这会重新出现之前被隐藏的重复内容，起初可能会让人感觉像是倒退。但实际上，这种重复通常比它所替代的分支架构要便宜得多。两个独立的小组件可以各自独立修改，无需每次编辑都去核对数十种无关的标志组合。
当重用机制能够维护一个单一、稳定的契约时，它才会带来好处；而一旦通过让某个组件同时秘密代表多种不同产品来实现重用，就会带来风险。
5. 从打开模态框的页面中移除模态状态
大型组件往往最终会充当模态框管理器。它们会记录每个对话框是否处于打开状态、当前正在编辑哪条记录、处于流程的哪个步骤、是否正处于保存过程中，以及上次出现的错误是什么。
通常页面本身只包含一行代码用于触发模态框的显示，但无论如何它都要负责管理该对话框的整个生命周期。
这就导致即使对话框完全不可见时，相关状态依然保持活跃。正确关闭对话框意味着要按特定顺序清除已选记录、草稿字段内容、验证错误以及待处理请求。之后再打开另一个对话框，则有可能意外地重复使用之前打开的对话框所留下的数据。
将任何复杂的对话框视为独立的功能，而非附加在页面上的条件性JSX元素，就能改变这种状况。此时页面的任务变为判断用户打算对哪条记录进行操作，而对话框本身则负责管理草稿数据、验证逻辑、内部处理步骤以及提交流程。
在某些情况下，只需在实际打开对话框时才将其加载即可自动重置其临时状态。而在其他情况下，状态需要在关闭后仍然保留，因此它会转入专用的草稿管理模块，而不会与页面的表格和筛选状态混在一起。
这种分离还显著提升了异步操作的安全性。编辑对话框在关闭时即可取消或丢弃过期的请求。保存操作可以自行决定在出现故障时是否保持对话框打开状态。页面不再需要协调那些它其实并不了解的内部表单机制。
该页面仍然掌控着表格与对话框之间的连接——它知道当前选中了哪条记录，以及编辑成功后应执行什么操作。但由于对话框是从该页面启动的，并不意味着它就必须掌控所有的字段和状态转换。
模态框虽然在视觉上看起来是叠加在屏幕之上的，但这种视觉层叠并不意味着它的整个状态生命周期都必须存在于该屏幕的组件中。
6. 将权限检查从分散的 JSX 中提取出来
授权逻辑往往会以少量逐步的方式渗入各个组件中：为普通用户隐藏某个按钮，当记录被归档后禁用某项菜单选项，只有管理员才能看到某些内容。
由于 JSX 使得添加新的检查条件变得极为简单，这类条件会不断增多：
{user.role === "admin" && record.status !== "archived" && (
<DeleteButton />
)}
当一个组件变得过于庞大时，它可能会包含多个看似相同但实际上略有差异的规则版本。有一个条件决定某个元素是否可见，另一个条件决定其处理函数是否会被触发，还有一个条件决定菜单项是否会被置灰。随着时间推移，这些版本会逐渐出现差异，不再保持一致。
这种差异主要会导致正确性错误，同时也会降低可读性。布局标记会与业务规则混杂在一起，任何阅读该组件的人都必须逐一分析散布在整棵结构中的权限表达式，才能理解页面的功能。
与其在 JSX 中分散放置原始的规则检查，不如提前计算出一组明确的权限配置：
const capabilities = getRecordCapabilities({
user,
record,
organization,
});
由此，该组件只需判断当前用户是否有权编辑、归档、导出或删除指定记录即可。这些名称反映的是实际的产品设计决策，而非直接暴露数据库字段或角色字符串。
需要明确的是，这并未将安全控制移至客户端。后端依然是真正的授权边界，这一点不会改变。前端的能力对象仅用于为用户界面提供统一的真实数据来源，避免在五个不同的可视化模块中重复实现相同的规则而导致数据不一致。
这还能让规则本身的测试变得容易得多。你无需渲染整个组件树，即可针对不同的角色、所有权配置、状态和组织设置来测试权限逻辑。当底层策略发生变化时，周围的组件通常根本无需改动。
当大型 JSX 树同时用于动态生成业务规则时，其稳定性会降低。渲染应当主要是使用已经做出的决策，而非在每个条件分支中从头重新构建这些决策。
7. 废除全页加载与错误标志
大多数大型组件最初都只有单一的 isLoading 状态和单一的 error 状态。只要页面只执行一项操作，这样就没问题。但随着功能日益复杂，这两个状态标识最终却要试图同时描述多项互不相关的操作。
一个页面可能正在获取初始数据、在后台刷新表格、保存表单、删除行以及导出报告——有时这些操作会发生在同一个会话中。一个共享的加载布尔值无法告诉你其中哪项操作正在执行中。当一个请求完成并将该标志设为 false 时，另一个完全不同的请求可能仍在运行。数据变更操作引发的错误会覆盖原本用于描述页面初始加载状态的错误。仅仅因为某个无关的后台刷新操作正在运行，整个界面就会卡住。
更好的方法是用与具体操作相关的状态来替代这些覆盖整个页面的状态标志。
这意味着在初始查询正在加载时，现有的表格仍可完全显示并保持交互性。单行数据可以在删除过程中，而不会导致页面上的其他行全部失效。编辑器可以在提交操作进行中，同时页面的筛选功能依然可用。导出操作可以显示自己的进度指示器，而不会让人觉得整个屏幕都不可用了。
这样虽然会有更多独立的状态值，但每个状态的含义都非常明确。代码无需猜测某个通用的isLoading在某一时刻具体指的是什么。
同样的逻辑也适用于错误处理：并非所有错误都必须汇总到同一个顶层错误界面。出现故障的可选面板可以直接显示自己的重试选项。变异错误则可以限制在触发它的工作流范围内。只有当渲染该页面所需的数据加载失败时，主页本身才会不可用。
这样不仅能打造出更具弹性的界面，还能让组件模型更易于理解。仅仅因为某个操作位于大型页面组件中，其状态就不再被视为全局性的。
大型组件往往显得不稳定，因为多个不同的工作流被迫共享同一个信号。为每个工作流设置独立的状态，能让界面准确反映当前哪些功能正常运行，哪些没有。
重点从来不只是更小的文件
一旦去除了这些模式，许多组件的长度确实会变短——但这只是副作用，并非最终目标。
真正的益处在于，在单个渲染范围内需要做出的无关决策减少了。子组件会收到限定在其自身职责范围内的契约，而非整个功能的所有状态信息。引用标识不再会在每次渲染时悄无声息地使庞大的子树失效。数据的获取会依据屏幕上实际显示的内容，而非通过一次覆盖整个页面的查询来完成。可复用组件也不必为人们可能需要的每一种变体都新增一个标志。
模态框能够自行管理自身的状态。权限规则会转变为有名称的能力，而非内联的条件语句。加载状态和错误状态则归属于生成它们的具体操作。
有些界面的屏幕尺寸依然很大，只是因为界面本身确实很庞大——这也没关系。代码更易于处理并非因为它变小了，而是因为它的规模反映了真实的、可见的结构，而非隐藏的协调逻辑。
此时，关于 React 组件值得探讨的问题不再是它有多少行代码，而是有多少独立的因素可能迫使它发生变化。如果要修改编辑器，就必须同时理解表格的查询逻辑、导出状态、权限模型以及页面上的每一个模态框，那么问题就不在格式或文件长度上，而在于职责边界划分得不对。
一旦大型 React 组件不再试图独自承担整个应用程序的功能，它们就能保持可管理性。
我们的目标从来不是不断拆分文件，直到每个函数都变得极小。
目标是确保每个功能模块仅知晓其实际负责做出的决策。
相关阅读
- 会拖慢现代应用速度的十种隐藏 React 组件陷阱 — 了解从语义 HTML 的缺陷到缺少记忆化处理等十种常见的 React 组件错误，以及为在2026年保持应用运行快速、易用且无漏洞所需采取的修复措施。
- 利用组合与插槽解决 React 属性过载问题 — 了解为何配置繁重的 React 属性会带来维护负担，以及控制反转、组合模式和插槽如何帮助创建真正可复用的组件。