Hooks 之后，为什么前端仍需要“包裹”能力？

Hooks 取代了许多不合适的 HOC 用法，但没有消除"围绕既有渲染目标施加规则"的需求。

讨论 HOC 是否过时时，很容易把两个问题混在一起：

1. 怎样复用组件内部的状态、请求、订阅和交互逻辑？
2. 怎样在一个既有组件或元素的渲染边界 外，独立地处理属性、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 仍在表达一个真实问题。

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

遇到可复用需求时，可以先问三个问题：

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

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

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

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

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

在 Cabloy/Zova 中，同样的自动聚焦需求可以用 Behavior 表达：

<input bs-behaviors-focus type="text" />

这里的 <input> 仍然只是一个输入框；"自动聚焦"是附着在它的渲染过程上的能力。对应的核心实现可以概括为：

@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 附着在 <input> 上。例如，定义一个接收普通原生 props 的 demo-ui:inputLayout Behavior，并在其中执行 const vnode = next(props) 后返回布局壳，使用时可以写成：

<input bs-demo-ui-inputLayout type="text" 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 复用逻辑
• React：Higher-Order Components（旧版文档）
• Cabloy：Behavior Guide
• BehaviorFocus 源码
• 表单字段布局 Behavior 源码
• 登录页选择字段布局 Behavior 的示例