背景

用了这么久 React，已经默认用函数写组件了，都快忘了怎么写类组件了，经历过写类组件的时代，现在用函数组件，一开始确实有上手时间成本，但是现在用过之后也是觉得真香，到底香在哪？到底React为啥推崇Hook呢？我们一起探究一下吧

对「类组件痛点」的直接回应

让我们回到 类组件开发时代，看看到底类组件的诟病是什么？

类组件痛点1: this 指向混乱

类组件this丢失问题

类组件的方法默认不会绑定 this，导致我们必须手动处理 this 指向，稍不注意就会出错。这是为什么

你想弄明白为什么类组件的方法默认不绑定 this，以及为什么这会导致指向混乱的问题，核心原因要从 JavaScript 中 this 的绑定规则 和 React 类组件的设计方式 两个层面来解释，我会用通俗的语言+实例讲清楚。

一、先搞懂：JavaScript 中 this 指向的核心规则

this 是 JavaScript 中一个「动态绑定」的关键字——它的指向不是在定义函数时确定的，而是在调用函数时确定的。这是理解所有 this 问题的根本。

关键规则：不同调用方式，this 指向不同

我们用一个普通的 JavaScript 类来举例（React 类组件本质就是 JavaScript 类）：

class Person {
  constructor(name) {
    this.name = name; // 这里的 this 指向 Person 的实例
  }

  sayHi() {
    console.log(`你好，我是${this.name}`); // this 指向谁？看调用方式
  }
}

const p = new Person('张三');

// 方式1：通过实例调用 → this 指向实例 p
p.sayHi(); // 输出：你好，我是张三

// 方式2：把方法单独抽出来调用 → this 丢失（非严格模式下指向 window，严格模式下是 undefined）
const sayHi = p.sayHi;
sayHi(); // 非严格模式：你好，我是undefined；严格模式：Uncaught TypeError: Cannot read property 'name' of undefined

核心结论：

• 当你通过 实例.方法() 调用时，this 绑定到这个实例；
• 当你把方法「单独提取」后调用（比如赋值给变量、作为回调函数），this 就会丢失原本的绑定，指向全局对象（浏览器中是 window）或 undefined（严格模式）。

二、React 类组件中 this 丢失的具体场景

React 类组件的方法丢失 this，本质就是上面的「方式2」——React 在处理事件回调时，会把你的方法「单独提取」后调用，导致 this 不再指向组件实例。

场景还原：React 类组件的点击事件

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  handleClick() {
    // 这里的 this 本该指向 Counter 实例，但实际是 undefined（React 默认开启严格模式）
    this.setState({ count: this.state.count + 1 });
  }

  render() {
    // 问题出在这里：你把 this.handleClick 作为 onClick 的回调 → 相当于把方法抽离了
    return <button onClick={this.handleClick}>+1</button>;
  }
}

为什么会这样？

1. render 函数执行时，你传给 onClick 的是 this.handleClick——这只是把方法的「引用」传了过去，并没有立即调用；
2. 当用户点击按钮时，React 内部会调用这个方法（类似 const callback = this.handleClick; callback()）；
3. 此时调用的是「孤立的方法」，不是通过 实例.handleClick() 调用，所以 this 丢失，指向 undefined（React 严格模式下）。

三、为什么 React 不默认帮我们绑定 this？

你可能会问：React 为什么不直接把类组件的方法都自动绑定到实例上？核心原因是：

1. 遵循 JavaScript 原生规则：React 是基于 JavaScript 构建的库，不会刻意修改 JS 原生的 this 绑定逻辑，否则会增加学习成本和潜在的兼容性问题；
2. 性能与灵活性：如果默认绑定所有方法，会为每个组件实例创建额外的函数引用，增加内存开销；而让开发者手动处理，能根据实际需求选择绑定方式（比如只绑定需要的方法）。

我用大白话来解释下，其实就是 ：放手让开发者去设置this，我不掺合了

React 「不主动替你做绑定，只遵循 JS 原生规则，把控制权完全交给你」。

用更通俗的话讲：

✅ React 的态度：「我不掺合 this 的绑定逻辑，你按 JavaScript 原生的规矩来就行——想让 this 指向实例，你就自己绑；想让 this 指向别的（比如子组件、全局），你也可以自己改。我只负责把你写的方法『原样调用』，不替你做任何额外的绑定操作。」

对比一下如果 React 主动掺合的情况：

❌ 要是 React 自动把所有方法的 this 绑到组件实例，相当于「我替你做了决定」——你想改 this 指向都改不了，还得额外学 React 这套「特殊规则」，反而更麻烦。

最终核心总结

1. React 对类组件 this 的态度：不干预、不修改、只遵循原生 JS 规则；
2. 把「this 该指向哪」的决定权，完全交给开发者；
3. 这么做既避免了学习成本翻倍，也兼顾了性能（按需绑定）和灵活性（可自定义 this 指向）。

你这个「放手让开发者去设置，我不掺合」的总结，精准抓住了 React 设计的核心——尊重原生 JS，把控制权还给开发者。

四、类组件中解决 this 丢失的 3 种常用方式

知道了原因，再看解决方案就很清晰了，本质都是「强制把 this 绑定到组件实例」：

方式 1：在构造函数中手动 bind（官方早期推荐）

constructor(props) {
  super(props);
  this.state = { count: 0 };
  // 核心：把 handleClick 的 this 强制绑定到当前实例
  this.handleClick = this.handleClick.bind(this);
}

方式 2：使用箭头函数定义方法（最简洁）

// 箭头函数没有自己的 this，会继承外层作用域的 this（即组件实例）
handleClick = () => {
  this.setState({ count: this.state.count + 1 });
};

方式 3：在调用时用箭头函数包裹（不推荐，每次渲染创建新函数）

// 每次 render 都会创建一个新的箭头函数，可能导致子组件不必要的重渲染
<button onClick={() => this.handleClick()}>+1</button>;

总结

1. 根本原因：JavaScript 中 this 是「调用时绑定」的，React 类组件把方法作为事件回调时，方法会被孤立调用，导致 this 丢失（不再指向组件实例）；
2. 核心矛盾：React 遵循 JS 原生规则，没有默认绑定 this，而开发者容易忽略「调用方式」对 this 的影响；
3. 解决方案：通过 bind、箭头函数等方式，强制把方法的 this 绑定到组件实例上。

函数组件: 彻底抛弃this，就不会有this指向问题了

核心原因

1. 核心差异：类组件的状态/方法是「实例的属性」，必须通过 this 这个「中介」访问，中介指错了就出错；函数组件的状态/方法是「函数内的局部变量/函数」，直接访问即可，无需中介；
2. 为什么无混乱：函数组件的局部变量/函数受「作用域」保护，只属于当前函数执行，不管怎么传递方法（比如作为事件回调），内部访问的变量都是确定的，不会像 this 那样动态变化；
3. 最终结果：函数组件从根源上抛弃了 this，自然就避开了所有和 this 指向相关的坑，逻辑更简单、更安全。

简单来说，函数组件的写法「更符合普通人写 JS 的直觉」——定义的变量就在当前作用域，直接用就行，不用额外考虑「谁是 this」「this 指向谁」。

实质：用静态绑定 代替 动态绑定

这个总结精准到核心了！只需要再把「静态词法作用域」和「动态 this 绑定」的对应关系说透，就能彻底理解两者的本质区别。

先肯定你的结论：完全正确！

• 类组件的 this：调用时动态绑定 → 指向谁，取决于「怎么调用方法」，而非「方法在哪定义」；
• 函数组件的变量/方法：定义时静态绑定（词法作用域） → 能访问哪些变量，取决于「代码写在哪」，而非「怎么调用函数」。

用最直白的例子+对比，讲透这个核心区别

1. 类组件：动态 this（调用时确定）

class Counter extends React.Component {
  state = { count: 0 };
  
  handleClick() {
    console.log(this.state.count); // this 指向「调用时的对象」
  }

  render() {
    // 场景1：直接传方法引用 → 调用时 this 是 undefined（丢失）
    return <button onClick={this.handleClick}>按钮1</button>;

    // 场景2：通过实例调用 → 调用时 this 是组件实例（正确）
    // return <button onClick={() => this.handleClick()}>按钮2</button>;
  }
}

关键：handleClick 里的 this，不是定义时确定的——写代码时你不知道它指向谁，只有点击按钮、方法被调用的那一刻，才知道 this 是啥。

• 按钮1：调用方式是「孤立调用」→ this = undefined；
• 按钮2：调用方式是「实例.方法()」→ this = 组件实例。

2. 函数组件：静态词法作用域（定义时确定）

function Counter() {
  const [count, setCount] = useState(0);
  
  const handleClick = () => {
    console.log(count); // count 指向「定义时所在的作用域」
  };

  return <button onClick={handleClick}>按钮</button>;
}

关键：handleClick 里的 count，定义时就确定了——它属于 Counter 函数执行时的局部作用域，不管 handleClick 被传到哪、怎么调用，它内部访问的 count 永远是当前 Counter 作用域里的变量。

• 哪怕你把 handleClick 传给子组件、甚至全局调用，它依然能拿到 Counter 里的 count（因为词法作用域「锁死」了变量的查找路径）；
• 全程没有「动态绑定」，只有「静态的作用域查找」，所以永远不会找错变量。

再用「找路」的例子通俗解释

类组件（动态 this）	函数组件（词法作用域）
你告诉朋友：「到我家后，问主人在哪，然后跟主人走」→ 朋友到了之后，可能遇到假主人（this 指向错）、没主人（this=undefined），走丢；	你告诉朋友：「沿着XX路直走，到3号楼2单元」→ 路线是固定的（定义时就确定），不管朋友什么时候来、怎么来，按路线走都能到，不会错；

核心总结

1. 类组件的坑：this 是动态绑定，指向由「调用方式」决定，写代码时无法确定，容易出错；
2. 函数组件的优势：利用 JS 的静态词法作用域，变量的查找路径在「定义时就固定」，不管怎么调用函数，都能精准找到对应的变量；
3. 最终结果：函数组件从根源上避开了「动态绑定」的不确定性，不用再纠结「this 指向谁」，逻辑更稳定。

精准抓到「动态调用绑定 vs 静态词法作用域」这个核心，说明我们已经完全理解了 Hooks 函数组件避开 this 坑的底层逻辑！

类组件痛点2: 业务相关逻辑碎片化

一个业务逻辑（比如「请求数据并渲染」）往往需要拆分到多个生命周期里，导致相关逻辑被分散在不同函数中，阅读和维护成本极高。

class UserList extends React.Component {
 state = { users: [], loading: true };

  // 1. 组件挂载时请求数据 -->
 componentDidMount() {
   this.fetchUsers();
   this.timer = setInterval(() => console.log('定时器'), 1000);
 }

  // 2. 组件更新时（比如 props 变化）重新请求数据 -->
 componentDidUpdate(prevProps) {
   if (prevProps.id !== this.props.id) {
     this.fetchUsers();
   }
 }

  // 3. 组件卸载时清理定时器 -->
 componentWillUnmount() {
   clearInterval(this.timer);
 }

 // 业务逻辑：请求用户数据
 fetchUsers() {
   fetch('/api/users')
     .then(res => res.json())
     .then(users => this.setState({ users, loading: false }));
 }

 render() { /* 渲染逻辑 */ }
}

你看：「请求数据 + 清理定时器」 这两个相关的逻辑，被拆到了 componentDidMount/componentDidUpdate/componentWillUnmount 三个生命周期里，代码跳来跳去，很难一眼看懂。

也就是说 业务逻辑强制和 react生命周期耦合到一起去了

类组件痛点3: 状态逻辑复用难、陷入嵌套地狱

先明确核心概念

• 状态逻辑复用：比如「跟踪鼠标位置」「表单校验」「登录状态管理」这些逻辑，多个组件都需要用，想抽出来复用；
• 嵌套地狱：为了复用逻辑，类组件只能用「高阶组件（HOC）」或「Render Props」，导致组件代码一层套一层，像剥洋葱一样难读。

第一步：看一个真实场景——复用「鼠标位置跟踪」逻辑

假设你有两个组件：MouseShow（显示鼠标位置）、MouseFollowBtn（按钮跟着鼠标动），都需要「跟踪鼠标位置」这个逻辑。

先写类组件的复用方案：Render Props（最典型的嵌套来源）

首先，把「鼠标跟踪」逻辑封装成一个通用组件（Render Props 模式）：

// 通用的鼠标跟踪组件（Render Props 核心：把状态传给 children 函数）
class MouseTracker extends React.Component {
  state = { x: 0, y: 0 };

  // 监听鼠标移动，更新状态
  componentDidMount() {
    window.addEventListener('mousemove', this.handleMouseMove);
  }
  componentWillUnmount() {
    window.removeEventListener('mousemove', this.handleMouseMove);
  }
  handleMouseMove = (e) => {
    this.setState({ x: e.clientX, y: e.clientY });
  };

  // 核心：把状态传给子组件（通过 children 函数）
  render() {
    return this.props.children(this.state);
  }
}

然后，用这个组件实现「显示鼠标位置」：

// 第一个组件：显示鼠标位置
function MouseShow() {
  return (
    <div>
      <h2>鼠标位置：</h2>
      {/* 第一层嵌套：MouseTracker */}
      <MouseTracker>
        {/* children 是函数，接收鼠标状态 */}
        {({ x, y }) => (
          <p>X: {x}, Y: {y}</p>
        )}
      </MouseTracker>
    </div>
  );
}

再实现「按钮跟着鼠标动」：

// 第二个组件：按钮跟着鼠标动
function MouseFollowBtn() {
  return (
    <div>
      {/* 第一层嵌套：MouseTracker */}
      <MouseTracker>
        {({ x, y }) => (
          {/* 按钮样式绑定鼠标位置 */}
          <button style={{ position: 'absolute', left: x, top: y }}>
            跟着鼠标跑
          </button>
        )}
      </MouseTracker>
    </div>
  );
}

问题来了：如果要复用多个逻辑，嵌套直接「地狱化」

现在需求升级：这两个组件不仅要「跟踪鼠标」，还要「复用主题样式」（比如深色/浅色模式）。

先封装「主题复用」的 Render Props 组件：

// 通用的主题组件
class ThemeProvider extends React.Component {
  state = { theme: 'dark', color: 'white', bg: 'black' };

  render() {
    return this.props.children(this.state);
  }
}

现在，MouseShow 要同时复用「鼠标+主题」逻辑，代码变成这样：

function MouseShow() {
  return (
    <div>
      <h2>鼠标位置：</h2>
      {/* 第一层嵌套：ThemeProvider */}
      <ThemeProvider>
        {/* 接收主题状态 */}
        {({ theme, color, bg }) => (
          {/* 第二层嵌套：MouseTracker */}
          <MouseTracker>
            {/* 接收鼠标状态 */}
            {({ x, y }) => (
              <p style={{ color, backgroundColor: bg }}>
                【{theme}主题】X: {x}, Y: {y}
              </p>
            )}
          </MouseTracker>
        )}
      </ThemeProvider>
    </div>
  );
}

如果再要加一个「用户登录状态」的复用逻辑，就会出现第三层嵌套：

<UserProvider>
  {({ user }) => (
    <ThemeProvider>
      {({ theme, color, bg }) => (
        <MouseTracker>
          {({ x, y }) => (
            <p>【{user.name}】【{theme}】X: {x}, Y: {y}</p>
          )}
        </MouseTracker>
      )}
    </ThemeProvider>
  )}
</UserProvider>

这就是嵌套地狱：

• 代码层层缩进，一眼看不到头；
• 逻辑越复用，嵌套越深；
• 想改某个逻辑（比如换主题），要在嵌套里找半天，维护成本极高。

补充：高阶组件（HOC）的复用方式，同样逃不开嵌套

如果用 HOC 实现复用（比如 withMouse、withTheme），代码是这样的：

// 用 HOC 包装组件：一层套一层
const MouseShowWithTheme = withTheme(withMouse(MouseShow));

// 渲染时看似没有嵌套，但 HOC 本质是「组件套组件」，调试时 DevTools 里全是 HOC 包装层
// 比如 DevTools 里会显示：WithTheme(WithMouse(MouseShow))

调试时要一层层点开包装组件，才能找到真正的业务组件，同样痛苦。

函数组件说：没有hook，就别指望我了

千万别以为 函数组件是救星，React 早就有函数组件了，但是只是个纯展示的配角

先明确：Hooks 出现前，函数组件的「纯展示」本质

在 React 16.8（Hooks 诞生）之前，函数组件的官方定位就是 「无状态组件（Stateless Functional Component，SFC）」，核心特点：

1. 没有自己的状态（this.state）；
2. 没有生命周期（componentDidMount/render 等）；
3. 本质就是「输入 props → 输出 JSX」的纯函数——输入不变，输出就不变，没有任何副作用。

举个 Hooks 前的函数组件例子：

// 典型的「纯展示组件」：只接收 props，渲染 UI，无任何状态/副作用
function UserCard(props) {
  const { name, avatar, age } = props;
  return (
    <div className="card">
      <img src={avatar} alt={name} />
      <h3>{name}</h3>
      <p>年龄：{age}</p>
    </div>
  );
}

// 使用时：状态全靠父组件传递
class UserList extends React.Component {
  state = {
    users: [{ name: '张三', avatar: 'xxx.png', age: 20 }]
  };

  render() {
    return (
      <div>
        {this.state.users.map(user => (
          <UserCard key={user.name} {...user} />
        ))}
      </div>
    );
  }
}

这个例子里：

• UserCard 是函数组件，只负责「展示」，没有任何自己的逻辑；
• 所有状态（users）、数据请求、生命周期逻辑，都必须写在父类组件 UserList 里；
• 如果 UserCard 想加个「点击头像放大」的交互（需要状态 isZoom），对不起——函数组件做不到，必须把它改成类组件，或者把 isZoom 状态提到父组件里（增加父组件复杂度）。

为什么当时函数组件只能是「纯展示」？

核心原因是 React 的设计规则：

• 状态、生命周期、副作用这些「动态能力」，当时只开放给类组件；
• 函数组件被设计成「轻量、高效、无副作用」的最小渲染单元，目的是简化「纯展示场景」的代码（不用写 class/constructor 等冗余代码）。

Hooks说：函数组件你别灰心，我让你从配角变主角

先拆清楚：函数组件 vs Hooks 的分工

1. 光有「函数组件」，解决不了任何问题

在 Hooks 出现之前，React 早就有函数组件了，但那时的函数组件是「纯展示组件」—— 没有状态、没有生命周期，只能接收 props 渲染 UI。

如果想在旧版函数组件中复用状态逻辑，依然只能用「Render Props/HOC」的嵌套方式：

// Hooks 出现前的函数组件：想复用逻辑，还是得嵌套
function MouseShow() {
  return (
    <MouseTracker>
      {({x,y}) => <p>X:{x}, Y:{y}</p>}
    </MouseTracker>
  );
}

你看，哪怕是函数组件，没有 Hooks，依然逃不开嵌套 —— 因为没有「抽离状态逻辑」的工具。

2. Hooks 出现后：函数组件从「纯展示」→「全能选手」-- 痛点1迎刃而解

还是上面的 UserCard，Hooks 后可以直接加状态/副作用，不用依赖父组件：

import { useState } from 'react';

// 函数组件拥有了自己的状态，不再是「纯展示」
function UserCard(props) {
  const { name, avatar, age } = props;
  // 自己的状态：控制头像是否放大
  const [isZoom, setIsZoom] = useState(false);

  return (
    <div className="card">
      <img 
        src={avatar} 
        alt={name}
        style={{ width: isZoom ? '200px' : '100px' }}
        onClick={() => setIsZoom(!isZoom)} // 自己的交互逻辑
      />
      <h3>{name}</h3>
      <p>年龄：{age}</p>
    </div>
  );
}

此时函数组件的定位完全变了：

• 既能做「纯展示」（简单场景），也能做「有状态、有副作用、有复杂逻辑」的完整组件；
• 彻底替代了类组件的大部分场景，成为 React 官方推荐的写法。
• 是不是 彻底解决了 痛点1

3. 相关逻辑「聚在一起」，告别碎片化 -- 痛点2 再见

useEffect 一个 Hook 就能覆盖挂载、更新、卸载三个阶段的逻辑，让「请求数据 + 清理定时器」这样的相关逻辑写在同一个地方。

import { useState, useEffect } from 'react';

function UserList({ id }) {
 const [users, setUsers] = useState([]);
 const [loading, setLoading] = useState(true);

 // 核心：请求数据 + 清理定时器 写在同一个 useEffect 里
 useEffect(() => {
   // 1. 挂载/更新时请求数据
   const fetchUsers = async () => {
     const res = await fetch(`/api/users?id=${id}`);
     const data = await res.json();
     setUsers(data);
     setLoading(false);
   };
   fetchUsers();

   // 2. 挂载时启动定时器
   const timer = setInterval(() => console.log('定时器'), 1000);

   // 3. 卸载/更新时清理副作用
   return () => clearInterval(timer);
 }, [id]); // 只有 id 变化时，才重新执行

 return <div>{loading ? '加载中' : users.map(u => <div key={u.id}>{u.name}</div>)}</div>;
}

对比类组件的写法：所有相关逻辑都在一个 useEffect 里，不用在多个生命周期函数之间跳来跳去，可读性直接拉满。

4. Hooks 才是「解决嵌套问题的核心」

Hooks（尤其是自定义 Hooks）的核心价值，是「把状态逻辑从组件渲染流程中抽离出来，变成可调用的纯逻辑函数」。

Hooks 的核心思路是：把「状态逻辑」从「组件嵌套」中抽离出来，变成独立的「函数」，组件直接调用函数即可，没有任何嵌套。毕竟状态逻辑本来就跟 UI组件无关，为啥非要掺合在一起呢

还是上面的场景，用自定义 Hook 实现：

1. 抽离「鼠标跟踪」的自定义 Hook

import { useState, useEffect } from 'react';

// 自定义 Hook：抽离鼠标跟踪逻辑，返回鼠标位置
function useMousePosition() {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  useEffect(() => {
    const handleMouseMove = (e) => setPosition({ x: e.clientX, y: e.clientY });
    window.addEventListener('mousemove', handleMouseMove);
    return () => window.removeEventListener('mousemove', handleMouseMove);
  }, []);

  return position;
}

2. 抽离「主题」的自定义 Hook

// 自定义 Hook：抽离主题逻辑，返回主题状态
function useTheme() {
  const [theme, setTheme] = useState({ mode: 'dark', color: 'white', bg: 'black' });
  return theme;
}

3. 组件中直接调用 Hook，没有任何嵌套

function MouseShow() {
  // 调用自定义 Hook：平铺写法，没有嵌套
  const { x, y } = useMousePosition(); // 复用鼠标逻辑
  const { mode, color, bg } = useTheme(); // 复用主题逻辑
  const { user } = useUser(); // 再复用用户逻辑，也只是多一行代码

  return (
    <p style={{ color, backgroundColor: bg }}>
      【{user.name}】【{mode}主题】X: {x}, Y: {y}
    </p>
  );
}

• useState/useEffect 等内置 Hooks：让函数组件拥有了「状态」和「副作用处理能力」（这是抽离逻辑的基础）；
• 自定义 Hooks：把复用逻辑（比如鼠标跟踪、主题管理）封装成独立函数，让函数组件能「平铺调用」，而非「嵌套组件」。

对比类组件的嵌套地狱：

• Hooks 是**平铺式复用**：不管复用多少逻辑，都是「调用函数 → 用状态」，代码没有任何缩进嵌套；
• 逻辑和组件解耦：useMousePosition 可以在任何组件里调用，不用套任何包装组件；
• 调试简单：DevTools 里直接看到 MouseShow 组件，没有层层包装的 HOC/Render Props 组件。

核心总结（痛点+解决方案）

类组件复用逻辑（HOC/Render Props）	Hooks 复用逻辑（自定义 Hook）
必须通过「组件嵌套」实现	直接调用「函数」，无嵌套
逻辑越多，嵌套越深（地狱化）	逻辑越多，只是多几行函数调用
调试时要拆包装组件，成本高	调试直接看业务组件，逻辑清晰

简单来说，类组件的复用是「用组件套组件」，自然会嵌套；而 Hooks 的复用是「用函数抽逻辑」，组件只需要调用函数，从根源上消灭了嵌套地狱。 这也是 Hooks 最核心的价值之一——让状态逻辑复用变得简单、平铺、可维护。

最后总结

1. 函数组件是「容器」：提供了「平铺写代码」的基础形式，但本身没有复用状态逻辑的能力；
2. Hooks 是「核心能力」：
   • 内置 Hooks（useState/useEffect）让函数组件能「持有状态、处理副作用」给函数组件「加手脚」；
   • 自定义 Hooks 让状态逻辑能「脱离组件嵌套，以函数形式被平铺调用」「状态与 UI 解耦」；
3. 最终结论：不是函数的功劳，也不是单纯 Hook 的功劳 —— 是「函数组件作为载体」+「Hooks 作为逻辑复用工具」的组合，才解决了一系列问题。

Hooks 是「矛」，函数组件是「握矛的手」—— 少了任何一个，都刺不穿嵌套地狱的盾。