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 type="text" />这里的<input>仍然只是一个输入框；“自动聚焦”是附着在它的渲染过程上的能力。对应的核心实现可以概括为：
@Behavior<IBehaviorOptionsFocus>()exportclassBehaviorFocusextendsBeanBehaviorBase<IBehaviorOptionsFocus,IBehaviorPropsInputFocus,IBehaviorPropsOutputFocus>{inputRef?:HTMLElement;protectedrender(props,next){constrefOuter=props?.ref;props={...props,ref:ref=>{if(this.$options.always||!this.inputRef){ref.focus?.();}this.inputRef=ref;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 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 的示例
