探索 Ant Design Form 的实现原理——从 HOC 到 Hooks
不爱动脑约 14 分钟❝作为前端开发者，表单几乎是我们日常工作中最频繁接触的组件。而 Ant Design Form 又是 React 开发者最常用的组件库。从简单的登录框到复杂的数据录入界面，它几乎无处不在。
❞
你是否曾好奇过它的实现原理？或者注意到从3.x到4.x版本时的那次重大变化？从Form.create()高阶组件到Form.useForm() Hooks API，这不仅是API设计的改变，更是整个表单状态管理思路的转变。
这种演进背后有着怎样的技术考量？旧版实现存在哪些局限？新版又是如何解决这些问题的？本文将带你深入理解 Ant Design Form 的实现原理，探索从高阶组件到 Hooks 的演进历程。
3.x 版本——HOC 模式
设计思想
在 3.x 版本中，Ant Design Form 的核心设计采用状态提升（State Lifting）策略。通过将表单控件（如 Input）和提交按钮的共有状态（values/errors）存储在它们最近的共同祖先组件中，实现了：
跨组件状态共享 统一校验逻辑 数据流集中管理
HOC 模式解析
高阶组件（Higher-Order Component，HOC）是该版本的核心实现模式，其本质是一个函数，接受一个组件返回一个新组件的函数式编程范式。核心优势包括：
「逻辑解耦」：分离表单逻辑与 UI 呈现 「复用能力」：通用表单逻辑可跨组件复用 「状态隔离」：维护独立的状态管理上下文
实战演示：Form 表单 HOC 版本简化实现
使用示例
我们从一个简单的使用示例开始：
const nameRules = {required: true, message: "请输入用户名！"};const passwordRules = {required: true, message: "请输入密码！"};@Form.create()class MyForm extends Component {componentDidMount() {this.props.form.setFieldsValue({username: "小明"});}submit = () => {const {getFieldsValue, validateFields} = this.props.form;console.log("submit", getFieldsValue());validateFields((err, val) => {if (err) {console.log("err", err);} else {console.log("校验成功", val);}});};render() {const {getFieldDecorator} = this.props.form;return (<div><h3>MyForm</h3>{getFieldDecorator("username", {rules: [nameRules]})(<Inputplaceholder="Username" />)}{getFieldDecorator("password", {rules: [passwordRules]})(<Inputplaceholder="Password" />)}<buttononClick={this.submit}>submit</button></div>);}}export default MyForm;
手写 Form.create()
以这个 demo 为例，如果我们要自己实现一个高阶组件来替代 Form.create() API，该如何着手呢？
HOC 核心架构初始化
首先高阶组件是接收一个组件，返回一个组件：
import React, {Component} from "react";export default function createForm(WrappedComponent) {return class extends Component {render() {return <WrappedComponent {...this.props} />;}};}
状态提升集中管理
文章开头我们提到过，它使用状态提升实现了对表单数据的统一管理，结合我们的示例，数据流向示意图如下：
Form.create()返回的HOC组件├── 存储表单状态└── 渲染 MyForm 组件 (对应WrappedComponent)├── 渲染 Input 控件 (username)├── 渲染 Input 控件 (password)└── 渲染 submit 按钮
那么如何在 HOC 中收集这些状态呢？ 首先给它创建一个 state 用于存储所有表单项的值：
return class extends Component {constructor(props) {super(props);this.state = {}; // 用于存储所有表单项的值}// ...}
至于收集，那就要依靠每个表单项外面包裹的 getFieldDecorator 了， 它是整个实现的关键：
getFieldDecorator = (field, options) => (InputComponent) => {return React.cloneElement(InputComponent, {name: field,value: this.state[field],onChange: this.handleChange,});};
这里采用了双层函数的设计：
第一层接收字段名和配置选项
第二层接收表单控件组件
最终返回注入了特定属性的克隆组件
通过 cloneElement，它为原始表单控件注入了三个关键属性：
name：字段标识，用于追踪状态 value：从 HOC 的 state 中读取值 onChange：统一的事件处理函数
当用户输入时，handleChange 方法被调用：
handleChange = (e) => {this.setState({[e.target.name]: e.target.value,});};
这里使用了计算属性名，根据事件对象的 name 属性更新对应的状态。这样一来，所有表单控件的状态变更都会统一流向 HOC 的 state。最后，通过 getForm 方法将 getFieldDecorator 传递给被包装组件，完整代码如下：
import React, { Component } from "react";export default function createForm(WrappedComponent) {return class extends Component {constructor(props) {super(props);this.state = {};}handleChange = (e) => {this.setState({[e.target.name]: e.target.value,});};getFieldDecorator = (field, options) => (InputComponent) => {return React.cloneElement(InputComponent, {name: field,value: this.state[field],onChange: this.handleChange,});};validateFields = () => {};getFieldsValue = () => {};setFieldsValue = () => {};getForm = () => {return {form: {getFieldDecorator: this.getFieldDecorator,validateFields: this.validateFields,getFieldsValue: this.getFieldsValue,setFieldsValue: this.setFieldsValue,},};};render() {return <WrappedComponent {...this.props} {...this.getForm()} />;}};}
这里为了防止代码报错，定义了 demo 中引用到的其他方法，正好大家也可以在这里暂停一下，拿这段代码作为起点，尝试自己实现 Form.create() 提供的其他的方法。
表单 API 封装 (get、set、校验)
getFieldsValue 和 setFieldsValue 实现起来是比较简单的：
getFieldsValue = () => {return { ...this.state };};setFieldsValue = (newState) => {this.setState(newState);};
这里我们重点看一下校验的实现：
export default function createForm(WrappedComponent) {return class extends Component {constructor(props) {super(props);this.state = {};this.options = {};}// ...getFieldDecorator = (field, options) => (InputComponent) => {this.options[field] = options;// ...};validateFields = (callback) => {let error = {};for (let field in this.options) {if (!this.state[field]) {error[field] = this.options[field].required;}}if (Object.keys(error).length > 0) {callback(error, this.state);} else {callback(null, this.state);}};// ...};}
整体工作流程：
在表单初始化时，this.options 为空对象 当使用 getFieldDecorator 装饰字段时，将校验规则存入 this.options 用户点击提交按钮时，调用 validateFields 方法 validateFields 遍历 this.options 中的所有字段进行校验 将校验结果通过回调函数返回给调用者
最终代码
import React, { Component } from "react";export default function createForm(WrappedComponent) {return class extends Component {constructor(props) {super(props);this.state = {};this.options = {};}handleChange = (e) => {this.setState({[e.target.name]: e.target.value,});};getFieldDecorator = (field, options) => (InputComponent) => {this.options[field] = options;return React.cloneElement(InputComponent, {name: field,value: this.state[field],onChange: this.handleChange,});};validateFields = (callback) => {let error = {};for (let field in this.options) {if (!this.state[field]) {error[field] = this.options[field].required;}}if (Object.keys(error).length > 0) {callback(error, this.state);} else {callback(null, this.state);}};getFieldsValue = () => {return { ...this.state };};setFieldsValue = (newState) => {this.setState(newState);};getForm = () => {return {form: {getFieldDecorator: this.getFieldDecorator,validateFields: this.validateFields,getFieldsValue: this.getFieldsValue,setFieldsValue: this.setFieldsValue,},};};render() {return <WrappedComponent {...this.props} {...this.getForm()} />;}};}
思考
HOC 实现的性能缺陷
HOC 模式虽然设计巧妙，但其核心缺陷在于状态提升导致的渲染效率问题。由于表单状态集中存储在 HOC 组件中，任何字段的变化都会触发整个组件树的重新计算：每当用户在输入框中输入内容时，会引发以下级联反应：
触发 handleChange 事件处理 执行 this.setState() 更新 HOC 状态树 HOC 组件因状态变化而重新渲染 作为子组件的 MyForm 接收新的 props 引用，触发完整重渲染 所有表单字段组件（包括未修改的）一同重新渲染
大家可以在 MyForm 的 render 函数中打个 console 验证一下。
这意味着即使用户仅修改 "用户名" 输入框，"密码" 输入框以及整个表单结构都会不必要地重新计算和渲染，在表单项较多或结构复杂时会造成明显的性能损耗。
HOC 优化的局限性
在 HOC 架构下，这类性能问题的解决面临多重障碍：
组件优化手段失效：即使在被包装组件上应用 React.memo 或使用 PureComponent，由于每次都会接收新的 props 引用，浅比较机制无法阻止重渲染 状态粒度问题：所有字段状态被合并在同一对象中（this.state），缺乏独立更新的机制，难以实现字段级的渲染优化 组件层级复杂化：HOC 模式增加了组件嵌套深度，使性能优化需要在多个层级协同处理，增加了维护难度 调试与追踪困难：由于 props 来源不直观，排查渲染性能问题时难以确定变更的确切来源
这些问题正是 React Hooks 设计所要解决的关键痛点，也解释了为什么表单实现会从 HOC 模式转向 Hooks 模式。
4.x/5.x 版本——Hooks API
设计思想
HOC 的状态提升存在一些固有的缺陷，比如组件嵌套层级过深、状态更新可能触发不必要的重渲染、状态管理逻辑与 UI 组件耦合等问题。那么，还有什么更好的方式来统一管理 Form 中的状态值呢？
我们可以借鉴 Redux 的思想，创建一个独立的数据管理仓库（FormStore），通过发布订阅模式来实现状态管理。这种方式的核心是：将状态管理从组件中抽离出来，统一由 FormStore 来管理，并规定好这个数据仓库的 get、set 方法。当状态发生变化时，FormStore 会通知相关的订阅者（表单项组件）进行更新，而不是触发整个表单树的重渲染。
这种实现方式不仅解决了 HOC 的固有问题，还为表单功能的扩展（如表单验证、依赖关系等）提供了更大的灵活性。通过发布订阅模式，我们可以实现更细粒度的状态更新，支持更复杂的表单联动，同时保持代码的可维护性和可测试性。
实战演示：Form 表单 Hooks 版本简化实现
使用示例
还是从一个简单的使用示例开始：
import React, { Component } from "react";import { Form, Button, Input } from "antd";const FormItem = Form.Item;const nameRules = { required: true, message: "请输入姓名！" };const passworRules = { required: true, message: "请输入密码！" };export default function MyForm(props) {const [form] = Form.useForm();const onFinish = (val) => {console.log("onFinish", val);};// 表单校验失败执行const onFinishFailed = (val) => {console.log("onFinishFailed", val);};useEffect(() => {console.log("form", form);}, []);return (<div><h3>AntdFormPage</h3><Formref={formRef}onFinish={onFinish}onFinishFailed={onFinishFailed}><FormItemrules={[nameRules]}><Inputplaceholder="username placeholder" /></FormItem><FormItemrules={[passworRules]}><Inputplaceholder="password placeholder" /></FormItem><FormItem><Buttontype="primary"size="large"htmlType="submit">Submit</Button></FormItem></Form></div>);}
架构设计
在开始编码之前，我们需要先规划好整体架构。从使用示例来看，我们的简化版 Form 需要以下部分：
Form 容器组件 Form.Item 表单项组件 FormStore 状态管理 Context 通信机制
/my-form├── FormContext.js - 用于传递表单实例├── Form.js - 表单容器组件├── index.js - 导出入口文件├── Item.js - 表单项组件└── useForm.js - 表单状态管理逻辑
入口文件
// index.jsimport React from "react";import _Form from "./Form";import Item from "./Item";const Form = React.forwardRef(_Form); //_Form;Form.Item = Item;export { Item };export default Form;
这里 React.forwardRef() 的作用是使 Form 组件能够接收并转发 ref 到其内部元素或组件。
使用 forwardRef 后：可以直接 <Form ref={myRef}>...</Form>，ref 会被正确传递不使用 forwardRef： <Form ref={myRef}>...</Form>中的 ref 会被忽略，无法传递到组件内部
❝在 React 19 中，所有函数组件都默认接收 ref 作为第二个参数。这意味着不再需要显式地使用 forwardRef 来包装组件，组件可以直接访问并使用 ref。
❞
Form.item 表单项组件
第一步，把 Form.Item 包裹的组件变成受控组件。这个过程与旧版 antd 中的 getFieldDecorator HOC 原理类似。实现受控组件的关键技巧在于使用 React.cloneElement '劫持'原始输入框，注入自定义的 value 和 onChange 属性，从而接管组件的数据流向。
import React from "react";export default function Item(props) {const { children } = props;const getControlled = () => {return {value: "初始值",onChange: (e) => {const newValue = e.target.value;console.log("新的值", newValue);},};};const returnChildNode = React.cloneElement(children, getControlled());return returnChildNode;}
初始化状态管理库
// useForm.jsclass FormStore {constructor() {this.store = {};}getFieldsValue = () => {return { ...this.store };};getFieldValue = (name) => {return this.store[name];};setFieldsValue = (newStore) => {this.store = {...this.store,...newStore,};};getForm = () => {return {getFieldsValue: this.getFieldsValue,getFieldValue: this.getFieldValue,setFieldsValue: this.setFieldsValue,};};}
那么当我们要使用 Form 的时候，应该在哪创建这个对象的实例呢？为避免表单状态丢失和重置，FormStore 实例应在组件首次渲染时创建一次，在多次渲染和状态更新时复用同一实例，只有在组件完全卸载后重新挂载时才创建新实例。这个场景我们应该想到 useRef：
❝使用 ref 可以确保：
❞
可以在重新渲染之间 「存储信息」（普通对象存储的值每次渲染都会重置）。 改变它 「不会触发重新渲染」（状态变量会触发重新渲染）。 对于组件的每个副本而言，「这些信息都是本地的」（外部变量则是共享的）。 改变 ref 不会触发重新渲染，所以 ref 不适合用于存储期望显示在屏幕上的信息。如有需要，使用 state 代替。
// useForm.jsimport { useRef } from "react";// ...export default function useForm(form) {const formRef = useRef();if (!formRef.current) {const formStore = new FormStore();formRef.current = formStore.getForm();}return [formRef.current];}
此时已经可以通过 useForm 钩子创建数据仓库实例了，但通过 useForm 钩子创建的表单数据仓库需要在 Form 组件树的各个层级间共享。由于表单组件（如 Form.Item、Input、Button 等）可能位于不同嵌套层级且需要统一访问表单状态，使用 props 逐层传递显然不够优雅。此时，React 的 Context API 提供了理想解决方案，允许我们在 Form 根组件提供数据仓库实例，并让任意层级的子组件直接访问，实现高效的跨层级状态共享。
表单组件间通信
首先，创建一个 Context 来共享表单实例：
// FormContext.jsimport { createContext } from "react";const FormContext = createContext();export default FormContext;
接下来，在 Form 组件中，我们使用 Provider 将表单实例提供给子组件树。Form 组件是整个表单的容器，负责创建表单实例并通过 Context 分发给子组件：
// Form.jsimport FormContext from "./FormContext";import useForm from "./useForm";export default function Form({ children, form }) {const [formInstance] = useForm(form);return (<form><FormContext.Providervalue={formInstance}>{children}</FormContext.Provider></form>);}
最后，在 Item 组件中，我们通过 useContext 访问表单实例，从而实现对输入控件的 "劫持"，将其转变为受控组件。这里的关键是 getControlled 方法，它为原始输入组件注入了 value 和 onChange 属性：
// Item.jsimport React, { useContext } from "react";import FormContext from "./FormContext";export default function Item(props) {const { children } = props;const formInstance = useContext(FormContext);const { getFieldValue, setFieldsValue } = formInstance;const getControlled = () => {return {value: getFieldValue(props.name),onChange: (e) => {const newValue = e.target.value;setFieldsValue({ [props.name]: newValue });console.log("新的值", newValue);},};};const returnChildNode = React.cloneElement(children, getControlled());return returnChildNode;}
不过，需要注意的是，目前的实现还缺少响应式更新机制。虽然我们能够修改表单状态，但当 value 被修改后，它只存在于 React 的数据结构中（即虚拟 DOM），只有当 React 执行渲染过程时，这个修改才会被应用到实际的 DOM 元素上。
即 value 是 input 上的属性，input 作为一个 HTML 元素，不重新渲染 React 组件是无法更新这个属性的。
没有渲染，变化就停留在虚拟 DOM 层面，用户界面上的 input 元素不会更新。要实现真正的响应式表单，我们还需要添加订阅发布机制，让 FormStore 在状态变化时能够通知相关的表单项组件进行更新。
通过发布订阅实现响应式更新
实现订阅
首先，我们需要建立一个中央存储系统来管理表单状态和订阅者：
// useForm.jsclass FormStore {constructor() {this.store = {}; // 存储表单值的仓库this.itemEntities = []; // 存储订阅者（表单项）的数组}registerItemEntities = (entity) => {this.itemEntities.push(entity); // 添加订阅者return () => {// 返回取消订阅的函数this.itemEntities = this.itemEntities.filter((item) => item !== entity);delete this.store[entity.props.name];};};getForm = () => {return {// ...registerItemEntities: this.registerItemEntities,};};}
「使用数组存储订阅者，」
itemEntities数组存储了所有需要响应数据变化的表单项组件。当表单数据发生变化时，我们可以遍历这个数组，通知每个订阅者进行更新。「为什么返回取消订阅函数？」 这是一个经典的订阅模式实现。返回的函数用于组件卸载时清理订阅关系，防止内存泄漏。这种设计让订阅和取消订阅的逻辑保持一致性。
「为什么同时删除 store 中的数据？」 当组件卸载时，对应的表单字段也应该从数据存储中移除，保持数据的一致性和内存的有效利用。
Item 组件中的订阅处理
// Item.js - 函数组件实现export default function Item(props) {const {children, name} = props;const {getFieldValue,setFieldsValue,registerItemEntities,} = React.useContext(FormContext);// 使用useReducer实现forceUpdate功能const [, forceUpdate] = React.useReducer((x) => x + 1, 0);React.useLayoutEffect(() => {// 向FormStore注册此Item组件const unregister = registerItemEntities({props,onStoreChange: forceUpdate, // 注册更新函数});// 组件卸载时通过清理函数取消订阅return unregister;}, []);// 组件渲染逻辑...}
这里为什么不能用 useEffect 呢？这是因为执行时机的差异：
useLayoutEffect会在浏览器执行绘制之前「同步调用」，确保在用户看到页面之前就完成了订阅useEffect是异步执行的，会导致「页面先渲染一次后再订阅」，造成闪烁或初始值不正确的问题
实现发布
发布机制负责在数据变化时通知所有相关的订阅者：
// useForm.jssetFieldsValue = (newStore) => {// 1. update storethis.store = {...this.store,...newStore,};// 2. update Itemthis.itemEntities.forEach((entity) => {Object.keys(newStore).forEach((k) => {if (k === entity.props.name) {entity.onStoreChange();}});});};
表单提交
表单提交需要一个统一的入口来处理成功和失败的回调：
// Form.jsimport React from "react";import FormContext from "./FormContext";import useForm from "./useForm";export default function Form({ children, form, onFinish, onFinishFailed },ref) {const [formInstance] = useForm(form);formInstance.setCallbacks({onFinish,onFinishFailed,});return (<formonSubmit={(e) => {e.preventDefault();formInstance.submit();}}><FormContext.Providervalue={formInstance}>{children}</FormContext.Provider></form>);}
「为什么每次渲染都调用 setCallbacks？」 由于函数组件每次渲染都会重新执行，onFinish 和 onFinishFailed 可能是新的函数引用。通过每次都调用 setCallbacks，确保 FormStore 中保存的始终是最新的回调函数。
表单校验
提交和校验需要 Form.Item 中的数据，所以也得放在 FormStore 中统一处理。
// useForm.jsvalidate = () => {let err = [];this.itemEntities.forEach((entity) => {const { name, rules } = entity.props;const value = this.getFieldValue(name);let rule = rules[0];if (rule && rule.required && (value === undefined || value === "")) {err.push({ [name]: rule.message, value });}});return err;};
总结
无论是 HOC 还是 Hooks 的实现方式，都蕴含着丰富的设计智慧值得我们深入学习。虽然 HOC 在现代 React 开发中逐渐被 Hooks 所取代，但其装饰器模式的核心思想依然具有重要的借鉴价值。
或许一直使用 antd Form 这样的成熟组件库并不会遇到什么问题，但当我们亲自动手实现 FormStore 时，就能更深刻地理解独立状态管理仓库的设计哲学。这种理解是可以举一反三的——我们能够更好地掌握 Redux、Zustand 等状态管理库的核心原理，也能深刻理解为什么 React 18 要推出 useSyncExternalStore 这样的 Hook 来解决并发渲染场景下的状态同步问题。
技术的每一次演进都是为了解决实际开发中遇到的具体问题。作为开发者，我们不应该仅仅满足于掌握 API 的使用方法，更重要的是要透过源码看到作者的技术理念和设计范式。代码本身只是这些抽象思想的具象表达，真正有价值的是隐藏在代码背后的设计哲学和解决问题的思维方式。