Hooks流行后前端为何仍需要包裹能力

在讨论高阶组件（HOC）是否已经过时时，许多人容易陷入一个常见误区——将两个本质不同的问题混淆在一起：

1. 如何复用组件内部的状态、请求、订阅和交互逻辑？
2. 如何在既有组件或元素的渲染边界之外，独立地处理属性、ref、布局和呈现策略？

对于第一个问题，答案已经非常明确：优先选择自定义 Hook。如果一个 HOC 仅仅是将 useQuery、useEffect 或 useState 搬到外层，再把结果通过 props 传回组件，那么它确实只是徒增了组件树层级与 props 转发。

然而，第二个问题并没有随着 Hooks 的流行而消失。关键不在于“这几行代码能否写进组件内部”，而在于一个更本质的追问：它究竟属于组件内部，还是组件外部？

Hooks 擅长复用内部逻辑

自定义 Hook 是现代 React 中处理状态与副作用逻辑最自然的方式，这一点已成为大多数团队的共识。举个例子，如果多个组件都需要订阅在线状态，将订阅逻辑抽成一个 useOnlineStatus() 即可。调用该 Hook 的组件仍可自由决定如何使用该状态以及渲染什么 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 本身的前提下，为其渲染过程附加“挂载后聚焦”的规则。

但它的表达成本确实不低：

• 必须构造一个新的组件类型；
• 当外部需要拿到输入节点时，要显式处理 forwardRef 与 ref 转发；
• 被包裹的组件也要支持相应的 ref 契约；
• 实际工程里还得考虑调试名称和静态属性的透传。

所以，更准确的结论不是“HOC 已经不能用了”，而是：当目标只是复用内部状态逻辑时，HOC 通常不是首选；但当规则确实属于渲染边界时，HOC 仍然在表达一个真实的问题。

判断标准：这条规则应该归谁？

遇到可复用的需求时，不妨先问自己三个问题：

1. 这是目标组件固有的行为，还是某些使用场景下才需要的策略？
2. 使用者是否应该可以独立地附加、移除或组合这条规则？
3. 它是否需要改写渲染输入、ref、输出结构，或者目标周围的呈现方式？

答案会引导我们选择不同的抽象方式：

• 如果规则是组件固有行为，放在组件内部，必要时使用 Hook；
• 如果它需要提供稳定、独立的 UI 契约，做成普通组件；
• 如果它只转换数据且不涉及渲染，用纯函数 helper；
• 如果它围绕一个既有目标来拦截或包裹渲染，并且需要独立组合，那就需要某种“包裹能力”。

React HOC、各种 Wrapper，以及 Cabloy/Zova 的 Behavior，都归属于最后一类问题的不同表达方式。它们并不是同一个运行时机制，但都在处理同一个场景：规则不应该被硬塞进目标本身。

Zova Behavior：把规则附着在渲染目标上

在 Cabloy/Zova 中，同样的自动聚焦需求可以用 Behavior 来表达，写法就简洁多了：

 复制代码type="text" />

这里的 仍然只是一个输入框；“自动聚焦”是附着在它渲染过程上的一个能力。对应的核心实现大致是这样：

 复制代码@Behavior<IBehaviorOptionsFocus>()
export class BehaviorFocus extends BeanBehaviorBase<
  IBehaviorOptionsFocus,
  IBehaviorPropsInputFocus,
  IBehaviorPropsOutputFocus
> {
  inputRef?: HTMLElement;  protected render(props, next) {
    const refOuter = props?.ref;    props = {
      ...props,
      ref: ref => {
        if (this.$options.always || !this.inputRef) {
          ref.focus?.();
        }
        this.inputRef = ref;
        refOuter?.(ref);
      },
    };    return next(props);
  }
}

做的事情并不复杂：

1. 接收当前渲染的 props；
2. 保留原有的 ref；
3. 注入新的 ref，在元素可用时调用 focus()；
4. 继续调用原有的 ref；
5. 用 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 附着在 上。比如，定义一个接收普通原生 props 的 demo-ui:inputLayout Behavior，在其中执行 const vnode = next(props) 后返回布局壳，使用时就可以写成：

 复制代码type="text" placeholder="请输入内容" />

这表示把 demo-ui:inputLayout 附着到原生 input 的渲染过程中：Behavior 继续渲染输入框，再把得到的 vnode 放进自己的布局结构里。它不需要改变 的职责，也不需要为这个场景专门再定义一个输入组件。

Cabloy Basic 的表单字段布局 Behavior 也是“先渲染、再包裹”的模式，但它运行在表单字段宿主中，依赖字段状态与布局配置；因此应该通过 ZFormField 和表单 provider 来使用，而不是直接附着到普通 上。原生元素场景，应该使用像 demo-ui:inputLayout 这样只处理普通输入 props 的独立 Behavior。

页面还可以选择不同的字段布局 Behavior。比如登录页在 ZForm 的 formProvider 中选择了 home-login:formFieldLayoutLogin，那么表单中所有字段都会自动附加这个字段布局 Behavior，进而呈现出统一的渲染风格：

 复制代码<ZForm
  formProvider={{
    behaviors: {
      FormFieldLayout: 'home-login:formFieldLayoutLogin',
    },
  }}
>
  {/* fields */}
ZForm>

这里最值得保留的分工是：字段负责字段本身；布局策略负责如何在当前页面包裹和呈现字段。

试想一下，如果把登录页的布局硬编码进每个字段组件，那不同页面的布局策略就会相互污染；如果每个页面都复制字段和布局代码，又会失去统一调整的入口。把布局做成可选择的渲染规则，既保留了字段的稳定契约，也保留了页面的呈现自由度。

选择哪种复用方式

这张表并不是说视觉需求一律都应该做成 Behavior。如果一个抽象本身就拥有稳定的界面和交互契约，普通组件通常是更清晰的选择。Behavior、HOC 和 Wrapper 的价值在于：它们让一条规则可以围绕一个既有目标存在，而不必变成目标组件不可分割的一部分。

小结

React 的经典 HOC 之所以显得“过时”，主要是因为它在过去被拿来解决了太多本该由 Hooks 解决的问题。

但“包裹”本身并没有过时。只要一个需求本质上涉及的是：

• 在渲染前拦截目标的 props 或 ref；
• 在目标外部统一加一层呈现或交互策略；
• 让多条横切规则能够独立声明和组合；

那就仍然需要 HOC、Wrapper 或 Zova Behavior 这类能力来承载。

延伸阅读

• React：通过自定义 Hook 复用逻辑
• React：Higher-Order Components（旧版文档）
• Cabloy：Behavior Guide
• BehaviorFocus 源码
• 表单字段布局 Behavior 源码
• 登录页选择字段布局 Behavior 的示例