React Hooks 源码解析（2）：组件逻辑复用与扩展
内容提要
本文介绍React组件状态逻辑复用的五种方案：Mixins因耦合高、命名冲突已被弃用；类继承不被推荐，React主张组合优于继承；高阶组件（HOC）通过函数包装组件实现复用，但存在嵌套过深、ref和静态属性等问题；Render Props以回调复用逻辑，同样有嵌套问题；Hooks可避免命名冲突和Wrapper Hell，是更优方案。
延伸解读
从 Mixins 到 Hooks：复用方案的演进逻辑
文章梳理的五种方案并非并列选项，而是按时间与问题驱动演进：Mixins 因耦合与命名冲突被弃用；类继承因破坏组件单一职责且覆盖生命周期而不被推荐；HOC 与 Render Props 虽能复用逻辑，却都带来 Wrapper Hell。Hooks 之所以被视为更优，正是因为它同时规避了命名冲突和嵌套过深这两个前序方案的核心痛点，体现了 React 团队从“组合优于继承”到“函数式复用”的一贯思路。
HOC 的实用代价：不止是嵌套过深
文章指出 HOC 除 Wrapper Hell 外还有多项实际成本：需手动声明 displayName 以便调试、对 TypeScript 类型化不友好、静态属性需手动拷贝、ref 无法完美传递（React 16.3 的 forwardRef 可解决），以及可能透传不相关 props 导致可读性变差。这些细节提醒读者，评估 HOC 时不能只看复用便利，还要考虑调试、类型与属性传递的维护负担。
识别身边的 HOC 与 Render Props
文章用具体例子说明这两种模式并不遥远：Redux 的 connect 返回的函数就是高阶组件，antd 的 Form.create() 同样基于 HOC；而 React Context 的 Consumer 以函数作为子元素，正是 Render Props 的典型形态。理解这些常见 API 背后的模式，有助于读者在阅读现有代码时快速判断复用方式，并意识到它们同样可能带来嵌套层级问题。
Q&A
React 组件逻辑复用有哪些方案？
文章介绍了五种方案：Mixins、类继承、高阶组件（HOC）、Render Props 和 React Hooks。
为什么 React 不再支持 Mixins？
Mixins 会导致代码过于耦合、同名 Mixin 无法同时使用（命名冲突），以及数量多时产生雪球效应般的复杂度，弊大于利，因此 React 已不再支持。
React 中为什么不推荐使用类继承来复用组件逻辑？
继承会使代码阅读困难（需到父组件定位未声明的方法），重写子组件生命周期会覆盖父组件生命周期，且 React 主张组合优于继承，Facebook 在成百上千组件中未发现需要使用继承的情况。
高阶组件 HOC 是什么？有哪些实现方式？
HOC 是一个函数，接受一个组件作为参数并返回一个新组件，本质是装饰器。有两种实现：继承式 HOC（反向继承）和代理式 HOC（属性代理）。
HOC 存在哪些缺点？
HOC 的缺点包括：Wrapper Hell（嵌套过深难调试）、需要显式声明 displayName、对 TypeScript 类型化不友好、无法完美使用 ref（React 16.3 的 forwardRef 可解决）、静态属性需手动拷贝、可能透传不相关的 props。
Render Props 是什么？它有什么问题？
Render Props 是将原本放组件的地方换成回调函数，从而在组件内获取子组件状态并使用。它会产生和 HOC 一样的 Wrapper Hell 问题。
React Hooks 相比其他复用方案有哪些优势？
Hooks 可以避免命名冲突（多个 Hook 互不影响）、避免 Wrapper Hell，并拥有函数组件的所有优点，同时通过 useState、useEffect、useRef 等 Hook 在函数组件中使用 State、生命周期和 ref。
