Hooks 取代了许多不合适的 HOC 用法但没有消除“围绕既有渲染目标施加规则”的需求。讨论 HOC 是否过时时很容易把两个问题混在一起怎样复用组件内部的状态、请求、订阅和交互逻辑怎样在一个既有组件或元素的渲染边界外独立地处理属性、ref、布局和呈现策略对于第一个问题今天通常应先考虑自定义 Hook。若一个 HOC 只是把useQuery、useEffect或useState搬到外层再通过 props 把结果塞回组件它往往只增加了一层组件树和 props 转发。但第二个问题并没有随着 Hooks 消失。关键不在于“这几行代码能不能写进组件”而在于这条规则究竟应由目标组件自己拥有还是应作为一个可选择、可替换、可组合的渲染策略存在Hooks 擅长复用内部逻辑自定义 Hook 是现代 React 中复用状态与副作用逻辑的自然方式。例如多个组件都需要订阅在线状态可以把订阅逻辑放进useOnlineStatus()调用它的组件仍然决定如何使用该状态、渲染什么 UI。这类逻辑的所有权在调用者内部组件使用数据、处理交互也拥有最终输出。Hook 不会凭空增加一个新的 UI 边界因此非常适合请求、状态、订阅、事件处理等复用。这也解释了为什么许多经典 HOC 显得笨重它们过去经常被用来解决本可由 Hook 直接解决的内部逻辑复用。不过Hook 并不是“在别处包一层渲染”的通用语法。一个需求如果本质是改写传给目标的 props、接管ref或者把目标渲染结果放进统一布局那么它讨论的是另一个边界。先看 React自动聚焦 HOC 在解决什么以“输入框挂载后自动聚焦”为例。若希望把它作为一个可以附加给不同输入组件的能力传统 React HOC 可以这样写function withAutoFocus(WrappedInput) { return React.forwardRef(function AutoFocus(props, outerRef) { const inputRef React.useRef(null); React.useEffect(() { inputRef.current?.focus(); }, []); return ( WrappedInput {...props} ref{node { inputRef.current node; if (typeof outerRef function) { outerRef(node); } else if (outerRef) { outerRef.current node; } }} / ); }); }使用时const AutoFocusInput withAutoFocus(TextInput); AutoFocusInput placeholder请输入内容 /这段代码当然可以工作而且它表达的需求完全合理在不改动TextInput本身的前提下为其渲染过程附加“挂载后聚焦”的规则。但它也暴露了经典 HOC 的表达成本必须构造一个新的组件类型当外部需要拿到输入节点时要显式处理forwardRef与 ref 转发被包裹组件也要支持相应的 ref 契约实际工程里通常还要考虑调试名称与静态属性的透传。因此更准确的结论不是“HOC 已经不能用”而是当目标只是复用内部状态逻辑时HOC 通常不是首选但当规则确实属于渲染边界时HOC 仍在表达一个真实问题。判断标准这条规则应该归谁遇到可复用需求时可以先问三个问题这是目标组件固有的行为还是某些使用场景才需要的策略使用者是否应该能独立地附加、移除或组合这条规则它是否需要改写渲染输入、ref、输出结构或目标周围的呈现答案会引导我们选择不同抽象如果规则是组件固有行为放在组件内部必要时使用 Hook如果它需要提供稳定、独立的 UI 契约做成普通组件如果它只转换数据且不涉及渲染使用纯函数 helper如果它围绕一个既有目标拦截或包裹渲染并且需要独立组合就需要某种“包裹能力”。React HOC、各种 Wrapper以及 Cabloy/Zova 的 Behavior都属于最后一类问题的不同表达方式它们不是同一个运行时机制但都在处理“规则不应被塞进目标本身”的场景。Zova Behavior把规则附着在渲染目标上在 Cabloy/Zova 中同样的自动聚焦需求可以用 Behavior 表达input bs-behaviors-focus typetext /这里的input仍然只是一个输入框“自动聚焦”是附着在它的渲染过程上的能力。对应的核心实现可以概括为BehaviorIBehaviorOptionsFocus()exportclassBehaviorFocusextendsBeanBehaviorBaseIBehaviorOptionsFocus,IBehaviorPropsInputFocus,IBehaviorPropsOutputFocus{inputRef?:HTMLElement;protectedrender(props,next){constrefOuterprops?.ref;props{...props,ref:ref{if(this.$options.always||!this.inputRef){ref.focus?.();}this.inputRefref;refOuter?.(ref);},};returnnext(props);}}它做的事情并不复杂接收当前渲染的 props保留原有的ref注入新的ref在元素可用时调用focus()继续调用原有ref用next(props)继续原本的渲染。这是一种很直接的渲染时组合Behavior 可以在“下一步渲染”之前调整输入而目标元素不必知道自己是否需要自动聚焦。需要注意的是Behavior 不是“Vue 版 HOC”。Zova 在 Vue 的运行时与响应式基础上提供 controller、bean 和 IoC 的应用架构Behavior 是其中用于渲染时拦截与组合的 Zova 原生能力。对本文而言重要的不是它的底层运行时细节而是它把“聚焦”表达成了可以附着在目标上的独立规则。不只改 props还可以包裹渲染结果自动聚焦展示的是“渲染前”能力改写下一步渲染的输入例如 props 或ref。另一类更能说明包裹价值的需求是表单字段布局。字段控件本身负责输入、取值和校验但不同页面可能希望以不同方式呈现它加标签、显示错误信息、插入前后缀或套上一层块级/行内布局。这时一个布局 Behavior 可以先得到字段原本的渲染结果再在外面增加呈现结构。其核心形状类似const vnode next(renderContext); return ( fieldset legend{label}/legend {vnode} {errorMessage} /fieldset );如果布局规则只服务于原生输入元素也可以直接把独立的布局 Behavior 附着在input上。例如定义一个接收普通原生 props 的demo-ui:inputLayoutBehavior并在其中执行const vnode next(props)后返回布局壳使用时可以写成input bs-demo-ui-inputLayout typetext placeholder请输入内容 /这表示把demo-ui:inputLayout附着到原生input的渲染过程Behavior 继续渲染输入框再把得到的 vnode 放进自己的布局结构中。它不需要改变input的职责也不需要为这个场景再定义一个专门的输入组件。Cabloy Basic 的表单字段布局 Behavior 也是“先渲染、再包裹”模式但它运行在表单字段宿主中依赖字段状态与布局配置因此应通过ZFormField和表单 provider 使用而不是直接附着到普通input。原生元素场景应使用像demo-ui:inputLayout这样只处理普通输入 props 的独立 Behavior。页面还可以选择不同的字段布局 Behavior。例如登录页在ZForm的formProvider中选择home-login:formFieldLayoutLogin从而让表单中所有字段都自动附加这个字段布局 Behavior进而呈现出一致的渲染风格ZForm formProvider{{ behaviors: { FormFieldLayout: home-login:formFieldLayoutLogin, }, }} {/* fields */} /ZForm这里最值得保留的分工是字段负责字段本身布局策略负责如何在当前页面包裹和呈现字段。如果把登录页布局硬编码进每个字段组件不同页面的布局策略就会相互污染如果每个页面都复制字段和布局代码又会失去统一调整的入口。将布局作为可选择的渲染规则正好保留了字段的稳定契约也保留了页面的呈现自由度。选择哪种复用方式需求优先选择原因复用状态、数据、订阅和组件内部交互自定义 Hook逻辑仍属于调用组件自己的边界。提供稳定、独立的 UI 结构与输入输出普通组件抽象本身拥有清晰的 UI 契约。转换数据或规范化选项不需要渲染上下文纯函数 helper不需要引入框架级渲染组合。改写 props/ref或包裹一个既有渲染目标HOC / Wrapper / Behavior规则属于目标周围且可能需要独立附着与组合。这张表不是说视觉需求一律都该做成 Behavior。一个抽象如果本身就拥有稳定的界面和交互契约普通组件通常更清楚。Behavior、HOC 和 Wrapper 的价值在于它们让一条规则可以围绕既有目标存在而不必变成目标组件不可分割的一部分。小结React 的经典 HOC 之所以显得“过时”主要是因为它过去被拿来解决了太多本该由 Hooks 解决的问题。但“包裹”本身并没有过时。只要需求本质上是在渲染前拦截目标的 props 或ref在目标外部统一加一层呈现或交互策略让多条横切规则能够独立声明和组合那么仍然需要 HOC、Wrapper 或 Zova Behavior 这类能力。过时的不是 HOC 的“包裹”思想而是“把一切复用都做成 HOC”的习惯。Hooks 适合内部逻辑复用包裹能力适合把横切规则附着并组合在渲染边界上。延伸阅读React通过自定义 Hook 复用逻辑ReactHigher-Order Components旧版文档CabloyBehavior GuideBehaviorFocus 源码表单字段布局 Behavior 源码登录页选择字段布局 Behavior 的示例