• 文档
• 技术博客
• 教程

本文是《前端精读周刊》系列技术指南之一，完整原文见 前沿技术/12.精读《React 高阶组件》.md。HOC（Higher-Order Component，高阶组件）是 React 中复用组件逻辑的核心进阶技巧，本文将以该精读为主体，完整讲解 HOC 的两种实现方式（Props Proxy 与 Inheritance Inversion）、适用范围判断标准，以及它在数据请求、Form 表单校验等真实场景中的落地写法，并延伸到 render props 与 Hooks 的演进对比，帮助读者在业务中做出正确的抽象选型。

引言：从高阶函数到高阶组件

高阶组件（higher-order component，HOC）是 React 中复用组件逻辑的一种进阶技巧。需要特别强调的是，它本身并不是 React 的 API，而是一种 React 组件的设计理念，是社区在实践中沉淀出的组合模式。众多 React 库已经证明了它的价值，例如耳熟能详的 react-redux 就是通过 HOC 把 store 注入到组件中的。

理解 HOC 最自然的路径是类比高阶函数（Higher-Order Function）：高阶函数是把函数作为参数传入到函数中并返回一个新的函数；这里把"函数"替换为"组件"，就是高阶组件了。用一行公式可以概括 HOC 的调用形态：

const EnhancedComponent = higherOrderComponent(WrappedComponent);

即：输入一个组件，输出一个增强后的新组件。需要注意的是，只理解概念只是万里长征第一步，HOC 的实现方式、适用范围、局限性以及与替代方案的比较，才是真正决定能否用好它的关键。下面从两种主流实现方式讲起。

高阶组件的两种核心实现方式

HOC 常见有两种实现方式：**Props Proxy（属性代理）**与Inheritance Inversion（反向继承）。二者能力边界与侵入性截然不同。

Props Proxy（属性代理）

Props Proxy 能够对 WrappedComponent 的 props 进行操作，提取 WrappedComponent 的 state，以及使用其他元素来包裹 WrappedComponent。它的核心思路是：HOC 在渲染层作为一层"代理"，把处理后的 props 传给被包裹组件。

一个值得注意的细节是，Props Proxy 作为一层代理具有隔离作用，因此传入 WrappedComponent 的 ref 将无法直接访问到其本身，需要在 Props Proxy 内部完成中转。此外，各个 Props Proxy 的默认名称是相同的（例如下面代码中的类名PP），导致在 React DevTools 中难以区分不同 HOC 增强后的组件，因此需要根据 WrappedComponent 进行不同命名。完整的参考实现如下：

function ppHOC(WrappedComponent) { return class PP extends React.Component { // 实现 HOC 不同的命名 static displayName = `HOC(${WrappedComponent.displayName})`; getWrappedInstance() { return this.wrappedInstance; } // 实现 ref 的访问 setWrappedInstance(ref) { this.wrappedInstance = ref; } render() { return <WrappedComponent { ...this.props, ref: this.setWrappedInstance.bind(this), } /> } } } @ppHOC class Example extends React.Component { static displayName = 'Example'; handleClick() { ... } ... } class App extends React.Component { handleClick() { this.refs.example.getWrappedInstance().handleClick(); } render() { return ( <div> <button onClick={this.handleClick.bind(this)}>按钮</button> <Example ref="example" /> </div> ); } }

这段代码中有三个关键点值得拆解：

1. displayName 命名：static displayName = \HOC(${WrappedComponent.displayName})`会在 DevTools 中显示为HOC(Example)这样的可读名称，避免多个 HOC 都显示成PP` 这类雷同名字，方便调试定位。
2. ref 中转：在render()中，ref被当作 props 传给 WrappedComponent（React 内部会把ref从普通 props 中剥离并作为实例引用处理），通过ref: this.setWrappedInstance.bind(this)回调把被包裹组件的真实实例存到 HOC 的this.wrappedInstance上。
3. 实例暴露：外部通过this.refs.example.getWrappedInstance()拿到被包裹组件的真实实例，从而绕过 Props Proxy 的隔离，直接调用handleClick()等实例方法。

这里@ppHOC是装饰器（Decorator）语法，需要 Babel 的 decorators 插件支持，它本质上是ppHOC(Example)的语法糖。react-redux 的connect也正是采用这种 Props Proxy 思路实现的：外层拦截 props 注入 dispatch 与 state 切片，内层再把完整 props 传给业务组件。

Inheritance Inversion（反向继承）

另一种实现是 Inheritance Inversion。此时 HOC 类继承了 WrappedComponent，这意味着 HOC 可以访问到 WrappedComponent 的 state、props、生命周期和 render 等方法：

function ppHOC(WrappedComponent) { return class ExampleEnhance extends WrappedComponent { ... componentDidMount() { super.componentDidMount(); } componentWillUnmount() { super.componentWillUnmount(); } render() { ... return super.render(); } } }

由于继承关系，HOC 类天然拥有父类的实例方法与状态，但同时带来两个关键约束：

• 同名方法覆盖：如果在 HOC 中定义了与 WrappedComponent 同名的方法，将会发生覆盖，此时就必须手动通过super进行调用了。例如上面代码中，HOC 自定义了componentDidMount与componentWillUnmount，都需要显式super.componentDidMount()才能保留父类原有的生命周期逻辑。
• 渲染劫持（Render Hijacking）：通过完全操作super.render()返回的元素树（React 元素树），可以真正实现渲染劫持——例如在渲染前插入/删除元素、修改子元素的 props，甚至直接不调用super.render()来阻止渲染。

这种方案依然是"继承"的思想，对 WrappedComponent 有较强的侵入性：父类的内部实现细节（state 结构、渲染输出）都被 HOC 直接耦合，因此在真实项目中并不常见。相比之下，Props Proxy 的"组合代理"思路更贴合 React 的组合哲学，应用更广。

高阶组件的适用范围：逻辑与 DOM 的三种关联

理解了实现方式之后，更现实的问题是：什么时候该用 HOC，什么时候该用普通父组件？

对比 HOC 范式compose(render)(state)与父组件（Parent Component）的范式render(render(state))，如果完全利用 HOC 来实现 React 的应用，将操作与 view 分离，也未尝不可，但却不优雅。HOC 本质上是统一功能抽象，强调逻辑与 UI 分离；而在实际开发中，前端无法逃离 DOM，逻辑与 DOM 的相关性主要呈现 3 种关联形式：

DOM 的渲染适合使用父组件，这是 React JSX 原生支持的方式，清晰易懂，最好能封装成木偶组件（Dumb Component）。HOC 适合做 DOM 不相关、又是多个组件共性的操作。一个典型的例子是 Form 场景：validator 校验操作是纯数据操作，被放到了 HOC 中；但 validator 的元信息（比如校验规则）没有放到 HOC 中。反过来，如果能把 Error 信息展示这类逻辑完全隔离，也可以放到 HOC 中（可结合下文 Form 的具体实践详细了解）。

典型场景一：数据请求（react-refetch）

数据请求是另一类 DOM 不相关的场景。react-refetch的实现就使用了 HOC，做到了高效和优雅——组件本身完全不关心请求如何发起、数据从哪来，只声明"我依赖哪些接口"：

connect(props => ({ usersFetch: `/users?status=${props.status}&page=${props.page}`, userStatsFetch: { url: `/users/stats`, force: true } }))(UsersList)

可以看到，connect返回的 HOC 接收一个"由 props 推导出请求描述"的函数：字符串形式（如/users?status=...&page=...）表示普通的 GET 请求，对象形式（如{ url: '/users/stats', force: true }）则可以附带force等请求行为配置。被包裹的UsersList组件完全只关心渲染，取数逻辑被整体隔离在 HOC 层，这正是"逻辑与 UI 分离"理念的落地。

典型场景二：通过 HOC 抽象 Form 表单校验

HOC 在真实场景中的运行非常多。Form 组件就是最能体现 HOC"良好扩展机制"的案例，下面通过 Form 组件的抽象来完整还原这一实践。

为什么 Form 必须抽象功能而非 UI

一个 Form 中会包含各种不同的组件，常见的有 Input、Selector、Checkbox 等，也会有根据业务需求加入的自定义组件。Form 灵活多变：

• 从功能上看：表单校验可能为单组件值校验，也可能为全表单值校验；可能为常规校验（如非空、输入限制），也可能需要与服务端配合，甚至需要根据业务特点进行定制；
• 从 UI 上看：校验结果显示的位置，可能在组件下方，也可能是在组件右侧。

直接裸写 Form 无疑是机械而又重复的。观察所有 Form 的共性路径：将 Form 中组件的 value 经过 validator，把 value 与 validator 产生的 error 信息储存到 state 或 redux store 中，然后在 view 层完成显示。这条路大家都是相同的，可以进行复用，只是我们面对的是不同的组件、不同的 validator、不同的 view 而已。

对于 Form 而言，既要满足通用，又要满足部分个性化的需求。以往单纯的配置化只会让使用愈加繁琐，因此我们所需要抽象的是Form 功能而非 UI——通过 HOC 针对 Form 的功能进行提取就成为了必然。

具体实现：formFactoryFactory 与 Decorator

首先将表单中的组件（Input、Selector...）与相应 validator 及组件值回调函数名（trigger）传入 Decorator，将 validator 与 trigger 相绑定。Decorator 完成了各种不同组件与 Form 内置 Store 间 value 的传递、校验功能的抽象——这正是精读文章中 Props Proxy 方式的其中两种作用：提取 state与操作 props：

function formFactoryFactory({ validator, trigger = 'onChange', ... }) { return FormFactory(WrappedComponent) { return class Decorator extends React.Component { getBind(trigger, validator) { ... } render() { const newProps = { ...this.props, [trigger]: this.getBind(trigger, validator), ... } return <WrappedComponent {...newProps} /> } } } } // 调用 formFactoryFactory({ validator: (value) => { return value !== ''; } })(<Input placeholder="请输入..." />)

这里出现了一个"工厂套工厂"的结构，值得展开：

• 最外层formFactoryFactory接收配置（validator 校验函数、trigger 事件名，默认onChange），它的作用是为不同组件定制化：每个表单控件可以传入自己的 validator 与触发时机；
• 中间层FormFactory(WrappedComponent)与内层Decorator是标准的 Props Proxy 形态：在render()中通过...this.props保留原有 props，再把[trigger]: this.getBind(trigger, validator)动态注入到 newProps 中——getBind内部会把"用户触发事件"与"validator 校验"绑定起来，形成值变化即校验的闭环。

这样一来，<Input>只需要声明"我的校验规则是 value 非空"，HOC 就自动替它完成了值同步与校验，UI 层零侵入。

Form Store 与个性化校验：setError 的用法

当然，为了考虑个性化需求，Form Store 也向外暴露很多 API，可以直接获取和修改 value、error 的值。例如：现在需要对一个表单的所有值提交到后端进行校验，根据后端返回，分别列出各项的校验错误信息，就需要借助相应项的setError去完成——先正常收集 value 提交后端，再逐项调用 setError 把后端返回的错误信息写回对应的字段。

这里主要参考了rc-form的实现方式。rc-form通过createForm这个 HOC 包装组件，在 props 中注入form对象，提供getFieldDecorator（字段装饰，绑定取值与规则）、getFieldError（读取字段错误）、validateFields（整体校验）等能力：

import { createForm } from 'rc-form'; class Form extends React.Component { submit = () => { this.props.form.validateFields((error, value) => { console.log(error, value); }); } render() { const { getFieldError, getFieldDecorator } = this.props.form; const errors = getFieldError('required'); return ( <div> {getFieldDecorator('required', { rules: [{ required: true }], })(<Input />)} {errors ? errors.join(',') : null} <button onClick={this.submit}>submit</button> </div> ); } } export createForm()(Form);

这段代码精确展示了 HOC 在 Form 场景的完整闭环：

1. createForm()(Form)将普通 Form 组件包装为"受控表单组件"；
2. getFieldDecorator('required', { rules: [...] })(<Input />)返回一个高阶"装饰函数"，把 Input 绑定到名为required的表单字段上，并注入校验规则——这本质上是 HOC 思想的函数化变体，返回的装饰函数内部依然是对组件的包装与 props 注入；
3. getFieldError('required')读取该字段当前错误，渲染到组件下方（errors ? errors.join(',') : null），解决"校验结果展示位置"的个性化问题；
4. validateFields((error, value) => ...)在提交时对全表单做统一校验，回调中拿到整体错误对象与值对象。

由此可见，rc-form把"值存取、校验、错误读取"全部抽象进了 HOC/装饰器层，业务组件只负责声明字段名与规则，同时通过form暴露的 API 保留了足够的个性化出口（如自定义 setError、自定义展示位置）。

HOC 的局限性：嵌套、命名冲突与 props 覆盖

掌握 HOC 的威力之后，同样需要正视它的代价。周刊后续的 前沿技术/31.精读《我不再使用高阶组件》.md 一文对 HOC 的问题做了集中剖析：

• 嵌套地狱与黑盒：HOC 可嵌套叠加，如果有一环 HOC 没有将内部 wrappedComponent 暴露出来，会导致后续叠加的 HOC 都无法获取、注入到原始组件；即使所有 HOC 都遵循规范，组件也难以察觉被注入的数据是由哪些 HOC 提供的；
• props 覆盖风险：HOC 之间互相隔离，多个 HOC 可能注入同名 props，导致相互覆盖的危险情况，而这些问题 HOC 都束手无策；
• 约定 vs 约束：HOC 依赖"命名规范"这类软约定（如所有 HOC 统一叫EnhancedComponent），而约定的可维护性低于硬约束。

正因为这些局限，社区才逐步演进出了替代方案，这也是理解 HOC 时不可缺失的一环。

替代方案的演进：render props 与 React Hooks

render props：看得见的数据流

针对 HOC 的嵌套黑盒问题，render props（也叫 render callback、function as child）方案直接把"要注入什么"写成 JSX 子元素函数：

import React, { Component } from 'react'; import PropTypes from 'prop-types'; class Caffeinate extends Component { propTypes = { children: PropTypes.func.isRequired }; state = { coffee: "Americano" }; render() { return this.props.children(this.state.coffee); } }

使用时将函数作为子元素，可以认为是一个匿名组件：

render( <Caffeinate> {(beverage) => <div>Drinking an {beverage}.</div>} </Caffeinate>, document.querySelector("#root") ); //=> Drinking an Americano.

相比 HOC，render props 的开放性提升明显：原本 HOC 所做的功能抽象可通过 render props 获取，render 函数内也可以访问到父级的一切；嵌套结构在 JSX 中一目了然，数据流动清晰可见，解决了 HOC 反复嵌套导致的各类问题（详见 前沿技术/31.精读《我不再使用高阶组件》.md）。

当然 render props 也有自己的短板：this.props.children本不该作为函数调用；渲染粒度变大，表格等需要性能优化的场景不适合；render props 渲染的并不是 React 组件，无法单独为其接入 redux、mobx、dob 等依赖收集粒度。因此在精读中也强调：这些最佳实践在不同场景、不同团队、不同项目下都有所侧重，不必追求唯一"完美"写法——在不为组件做注入的场景下（如利用生命周期实现权限、埋点），层级少时 HOC 依然非常方便。

React Hooks：官方给出的第三种状态共享方案

React Hooks 被官方定位为继 render props 和 HOC 之后的第三种状态共享方案（准确说是"状态逻辑复用"——只共享数据处理逻辑，不共享数据本身），并且不会产生 JSX 嵌套地狱问题。以useState为例：

function App() { const [open, setOpen] = useState(false); return ( <> <Button type="primary" onClick={() => setOpen(true)}> Open Modal </Button> <Modal visible={open} onOk={() => setOpen(false)} onCancel={() => setOpen(false)} /> </> ); }

这段代码等价于一个内置的"打平 renderProps"：随时创建一个值，与修改这个值的方法，同时保持代码平铺、无嵌套。Hooks 还可以引用其他 Hooks（自定义 Hook 组合），更容易将组件的 UI 与状态分离（详见 前沿技术/79.精读《React Hooks》.md）。从精读 前沿技术/132.精读《正交的 React 组件》.md 的正交性视角看，Hooks 解决了状态管理与 UI 分离的问题，与 HOC 的"逻辑与 UI 分离"追求一脉相承，但约束更强（use命名约定、顶层调用顺序），也因此更可预期。而从 前沿技术/95.精读《Function VS Class 组件》.md 的角度看，Function Component + Hooks 还天然具备 capture props / capture value 特性，进一步强化了"纯函数化 UI 组件"的写法。

需要说明的是，HOC 并未因此消亡：react-redux、react-refetch、rc-form 等生态依然以 HOC 为根基；对于无法使用 Hooks 的 Class 组件场景、以及"按层注入能力"这种正交抽象的诉求，HOC 仍是简洁可靠的选项。

总结

React 始终强调组合优于继承的理念，期望通过复用小组件来构建大组件，使开发变得简单而又高效，这与传统面向对象思想是截然不同的。HOC 的出现替代了原有 Mixin 侵入式的方案——对比隐式的 Mixin 或是继承，HOC 能够在 DevTools 中显示出来（通过 displayName），满足抽象之余，也方便了开发与测试。

回到本精读的完整脉络，值得记住的核心结论有三条：

1. 实现上：Props Proxy 通过组合代理实现（可操作 props、提取 state、包裹元素、中转 ref），Inheritance Inversion 通过继承实现（可访问 state/生命周期、可渲染劫持），前者更贴合 React 组合哲学、应用更广；
2. 选型上：与 DOM 强相关用父组件，与 DOM 无关的共性逻辑（校验、权限、请求、数据转换）用 HOC，完全内聚的交叉场景两者皆可；
3. 心态上：不可过度抽象是始终要秉持的原则。HOC、render props 与 Hooks 各有适用边界，结合具体的业务开发场景做取舍，比追逐"最完美实践"更有价值。

延伸阅读：本文内容源自周刊第 12 期精读，与 前沿技术/31.精读《我不再使用高阶组件》.md（HOC 的局限与 render props 对比）、前沿技术/79.精读《React Hooks》.md（Hooks 作为第三种状态共享方案）、前沿技术/132.精读《正交的 React 组件》.md（正交抽象视角）、前沿技术/95.精读《Function VS Class 组件》.md（函数组件的演进）互为补充，可在 readme.md 中查看周刊全部主题索引。

• 文档
• 技术博客
• 教程