讲座主题：React 依赖项检查的静态分析算法：探究 eslint-plugin-react-hooks 如何利用 AST 模拟 Hooks 指针移动

各位老铁，大家下午好！

今天我们不聊那些花里胡哨的 UI 动画，也不聊那些让人头秃的 Redux 架构。我们来聊聊 React 生态中最“隐秘”也最“硬核”的话题——Hooks 的规则。

大家肯定都用过 eslint-plugin-react-hooks。当你把代码写得乱七八糟，比如在 if 语句里写 useState，或者在 for 循环里写 useEffect 时，这个插件就会像个啰嗦的老太太一样跳出来报错。

但你有没有想过，这个插件到底是怎么知道你在 if 里面调用了 useState 的？难道它真的把你的代码跑了一遍吗？当然不是。它是通过一种叫做 AST（抽象语法树） 的技术，配合一种“指针移动”的算法，在代码的骨架上进行了一场“猫捉老鼠”的游戏。

今天，我就带大家深入这个黑盒，扒开 eslint-plugin-react-hooks 的裤衩（不是），看看它到底在 AST 里干了什么。

---

第一部分：Hooks 的“诅咒”与 ESLint 的“法眼”

首先，我们要明确一个概念：React Hooks 有两条铁律，死规定，违反了 React 核心库里会直接给你扔个 Warning，虽然不一定会崩，但那就是在裸奔。

1. 只在顶层调用：不能在循环、条件语句、嵌套函数中调用。
2. 只在 React 函数组件或自定义 Hook 中调用。

为什么要有这两条？因为 React 是靠顺序来管理状态的。useState 的第三个参数是一个 prev 函数，它依赖于上一次的值。如果顺序乱了，React 就像是在玩“接龙”，结果你把牌扔到了地上，它就不知道该接哪张了。

于是，我们需要一个工具来强制执行这个规则。eslint-plugin-react-hooks 就是这个工具。它不是靠运行时，而是靠静态分析。

所谓的静态分析，就是不看代码怎么跑，只看代码长什么样。这就好比我们不用去菜市场买菜，而是直接看菜谱（AST），分析食材（代码）能不能做成一道好菜。

---

第二部分：AST —— 代码的“骨架”与“翻译官”

要理解这个插件，你必须先懂一点 AST。别怕，我不会给你背定义。

想象一下，你写了一段 JavaScript 代码：

function App() {
  const [count, setCount] = useState(0);
  return <div>Hello</div>;
}

人类看到的是逻辑，是功能。但计算机（或者说 AST 解析器）看到的是结构。这段代码在 AST 里长这样（简化版）：

{
  type: 'FunctionDeclaration', // 函数声明
  id: { name: 'App' },
  body: {
    type: 'BlockStatement', // 代码块 {
      type: 'VariableDeclaration', // 变量声明 {
        type: 'VariableDeclarator', // 变量声明者
        id: { name: 'count' },
        init: {
          type: 'CallExpression', // 函数调用！
          callee: { name: 'useState' },
          arguments: [ ... ]
        }
      }
    }
  }
}

看到了吗？CallExpression 就是那个“函数调用”的节点。eslint-plugin-react-hooks 的核心工作，就是拿着这个“骨架”，在各个节点之间跳来跳去。

它不关心你的 count 是多少，它只关心这个 CallExpression 的名字是不是 useState。

---

第三部分：指针移动算法 —— 侦探的行走路线

这是今天的重头戏。我们要模拟 eslint-plugin-react-hooks 的核心算法。

核心思想：模拟一个指针在代码骨架上移动，并维护一个计数器。

这个插件是怎么运作的呢？它首先会遍历 AST，找到所有的函数组件（function、const 声明、箭头函数）。一旦找到，它就进入这个函数，初始化一个 hookCount = 0。

然后，它就开始在这个函数的“身体”里上下左右扫描。这就像是一个拿着手电筒的侦探，在黑暗的房间里找东西。

1. 识别“嫌疑人”：Hook 调用

当指针扫到一个 CallExpression（函数调用）时，它会停下来，看看调用的函数是谁。

// 代码
useEffect(() => { ... }, []);

在 AST 里，这对应一个节点：

{
  type: 'CallExpression',
  callee: { name: 'useEffect' } // 嫌疑人名字是 useEffect
}

如果这个 callee.name 在 hooksList（内置 Hooks 列表：useState, useEffect, useContext 等）里，那么恭喜，这就是一个 Hook 调用！

2. 指针的“禁行区”：条件与循环

这是算法最狡猾的地方。React 规定 Hooks 必须在顶层。也就是说，如果在调用 useState 之前，你已经进入了某个 if 或者 for 语句内部，那就绝对不行。

算法是如何知道你进入了 if 内部的呢？

指针在移动过程中，会遇到各种各样的节点类型：

• IfStatement (if 语句)
• ForStatement (for 循环)
• WhileStatement (while 循环)
• SwitchCase (switch case)

当指针遇到这些节点时，它会检查当前的 hookCount。

• 情况 A：hookCount === 0
  指针说：“没事，我还没调用过 Hook，我正准备调用第一个，这里是个 if，没关系，我钻进去看看。”
  指针继续向下移动。

• 情况 B：hookCount > 0
  指针尖叫一声：“卧槽！警报！警报！我已经调用了 useState，现在居然钻进了 if 语句里面！这违反了规则！”

  这就是 eslint-plugin-react-hooks 抓到你的瞬间。

  算法会检查这个 IfStatement 内部是否包含任何 Hook 调用（CallExpression）。如果包含，就报错。

3. 指针的“重置”：嵌套函数

这又是一个经典的坑。

function App() {
  useState(1); // 第一个 Hook

  function inner() {
    useState(2); // 第二个 Hook
  }
}

指针进入 App，初始化 hookCount = 0。
指针遇到 useState(1)，hookCount 变成 1。
指针继续移动，遇到了 function inner() { ... }。

这是一个 FunctionDeclaration（或者 FunctionExpression）。
这时候，指针怎么处理？

React 的规则是：Hooks 只能在组件顶层调用。这意味着，你不能在组件内部再定义一个函数来调用 Hook。

所以，当指针遇到一个新的函数定义时，它会重置 hookCount 为 0。

为什么？因为那个 inner 函数是一个独立的代码块。虽然它在 App 里面，但在 React 的逻辑里，inner 不算“组件的顶层”。如果允许在里面调用 useState，那顺序就乱了。

所以，指针进入 inner 时，hookCount 变回 0。如果 inner 里调用了 useState，那是合法的（虽然语义上很奇怪，但语法上不违规）。

4. 指针的“跳跃”：递归与嵌套组件

组件可能会调用子组件。

function Parent() {
  useState(1); // Hook 1

  function Child() {
    useState(2); // Hook 2
  }

  return <Child />;
}

指针在 Parent 里，hookCount 是 1。
指针往下走，遇到了 function Child()。它重置 hookCount 为 0。
指针继续走，遇到了 <Child />。这是一个 JSX 元素，指针直接跳过它（或者进入它进行递归）。

当指针进入 Child 函数体时，hookCount 再次被初始化为 0。
指针在 Child 里遇到 useState(2)，hookCount 变成 1。
指针结束，返回 Parent。

注意！ eslint-plugin-react-hooks 的逻辑是独立的。它不会因为你在 Parent 里调用过 Hook，就禁止你在 Child 里调用 Hook。每个组件都是独立的个体，顺序从零开始。

---

第四部分：代码示例与 AST 节点实战

为了让大家更直观地理解，我们来看一段代码，以及插件大概会怎么“扫描”它。

场景一：经典的违规代码

function BadComponent() {
  const [name, setName] = useState('Alice'); // Hook 1: hookCount = 1

  if (name === 'Bob') { // 指针进入 IfStatement
    const [age, setAge] = useState(20); // Hook 2: 违规！
  }

  return <div />;
}

AST 扫描过程模拟：

1. 进入 BadComponent：hookCount = 0。
2. 扫描到 useState('Alice')：
   • 节点类型：CallExpression。
   • callee.name：useState。
   • 判定：是 Hook。
   • 状态：hookCount 变为 1。
3. 扫描到 if (name === 'Bob')：
   • 节点类型：IfStatement。
   • 检查：当前 hookCount 是 1。
   • 判定：进入“危险区域”。
   • 动作：继续扫描该节点下的子节点。
4. 扫描到 useState(20)：
   • 节点类型：CallExpression。
   • callee.name：useState。
   • 检查：当前 hookCount 是 1。
   • 报错！：在 IfStatement 内部调用 Hook。

场景二：循环中的 Hook

function BadComponent() {
  for (let i = 0; i < 10; i++) {
    useEffect(() => {}, []); // 违规！
  }
}

AST 扫描过程模拟：

1. 进入 BadComponent：hookCount = 0。
2. 扫描到 for (let i = 0...)：
   • 节点类型：ForStatement。
   • 检查：当前 hookCount 是 0。
   • 判定：安全，继续向下扫描。
3. 扫描到 useEffect(...)：
   • 节点类型：CallExpression。
   • 判定：是 Hook。
   • 报错！：虽然 hookCount 是 0，但是在 ForStatement（循环）内部。规则禁止在循环中调用 Hook。

---

第五部分：进阶技巧——如何欺骗 AST

既然我们知道了它是基于 AST 扫描的，那我们能不能“作弊”？

1. eslint-disable 注释

这是最简单的作弊方式。

function App() {
  // eslint-disable-next-line react-hooks/rules-of-hooks
  if (true) {
    useState(1);
  }
}

当插件扫描到 // eslint-disable-next-line 时，它会跳过下一行代码的检查。这就好比你在侦探面前放了个烟雾弹，告诉他：“别管这行，忽略它。”

2. 箭头函数与 Hoisting

有时候，为了代码风格，我们会把 Hook 放在箭头函数里。

function App() {
  const handleLogin = () => {
    const [token, setToken] = useState('abc'); // 违规！
  };
}

AST 扫描过程模拟：

1. 进入 App：hookCount = 0。
2. 扫描到 const handleLogin = () => {：
   • 节点类型：VariableDeclarator。
   • init.type：ArrowFunctionExpression。
   • 动作：遇到箭头函数，重置 hookCount = 0。
3. 扫描到 useState('abc')：
   • 节点类型：CallExpression。
   • 判定：是 Hook。
   • 报错！：在箭头函数内部调用 Hook。

3. 高阶组件（HOC）的陷阱

HOC 会包裹组件。如果插件傻乎乎地直接扫描 HOC 返回的函数，可能会漏掉一些东西。

function withAuth(Component) {
  return function WrappedComponent() {
    // 这里调用 Hook 是合法的，因为这是组件内部
    const user = useUser();
    return <Component user={user} />;
  };
}

插件必须能够识别这种模式。它会检查 Component 是否是函数声明，如果是，它会在那个函数内部进行扫描。对于 HOC，它通常会把 WrappedComponent 当作一个独立的组件来处理，初始化新的 hookCount。

---

第六部分：为什么它用的是 Babel AST 而不是 ESTree？

这是一个非常细节但很重要的技术点。

传统的 ESLint 插件通常使用 ESTree 规范。但是，eslint-plugin-react-hooks 使用的解析器是 Babel。

为什么？

因为 React 的代码经常包含一些“现代语法”，比如：

• 装饰器 (@connect)
• 类属性 (this.state = {})
• TSX (TypeScript JSX)

ESTree 的标准解析器对某些 TSX 语法支持并不完美（或者解析出来的结构不一样）。Babel 的 AST 对 JSX 支持极其友好。

当你运行 eslint-plugin-react-hooks 时，它实际上是在后台调用 Babel Parser 把你的代码转成 Babel 的 AST，然后在这个 AST 上跑它的逻辑。

这意味着，如果你在 AST 遍历的时候写错了节点类型（比如把 CallExpression 写成了 CallExpression 的子类型），你可能会漏掉一些 Hook。

举个例子，在 Babel AST 中，useEffect 这种调用可能会被解析成 CallExpression。但如果你在递归遍历 FunctionDeclaration 的时候，忘记进入 ArrowFunctionExpression，你就抓不到箭头函数里的 Hook 了。

---

第七部分：算法的复杂度与性能

你可能会问，这个算法效率高吗？

时间复杂度：O(N)

其中 N 是 AST 中节点的数量。这基本上就是线性扫描。对于一个包含 500 行代码的组件，AST 大概有 1000 个节点，插件跑起来几乎是一瞬间的事，没有任何性能损耗。

空间复杂度：O(1)

它不需要存储整个 AST，只需要在遍历的时候维护一个 hookCount 变量和当前的 path（遍历路径）。这就是为什么它不需要安装庞大的依赖，只需要一个轻量级的 Babel 解析器。

---

第八部分：自定义 Hooks 的处理

如果我在一个自定义 Hook 里调用 useState，算不算违规？

function useCustomHook() {
  const [data, setData] = useState('default'); // 这里算违规吗？
  return data;
}

function App() {
  const data = useCustomHook();
}

AST 扫描过程模拟：

1. 进入 useCustomHook：hookCount = 0。
2. 扫描到 useState('default')：
   • 判定：是 Hook。
   • 允许！：因为 useCustomHook 本身就是一个函数，虽然它不是组件，但它是自定义 Hook。React 允许自定义 Hook 内部调用 Hooks。
3. 进入 App：hookCount = 0。
4. 扫描到 useCustomHook()：
   • 判定：这是一个函数调用，但 callee 是 useCustomHook（自定义 Hook），不是 useState（内置 Hook）。
   • 允许！：自定义 Hook 的调用不消耗 hookCount。

---

第九部分：总结——指针的哲学

通过这一系列的讲解，我们可以看到 eslint-plugin-react-hooks 的本质。

它并不是在运行你的代码，它是在阅读你的代码。它假装自己是一个指针，从函数组件的入口开始，一步步向下移动。每遇到一个 if，它就紧张地看看自己手里抓了多少个 Hook；每遇到一个新的函数，它就清空计数器，重新开始。

这种“基于顺序的假设”，赋予了 React Hooks 极致的性能（不需要闭包追踪）和简洁性，但也带来了巨大的约束。

而 eslint-plugin-react-hooks，就是那个拿着手电筒的守夜人，它用 AST 这把手术刀，精准地切除了那些可能导致状态混乱的代码块。

下次当你看到红色的报错提示时，不要抱怨它烦人。你应该感谢它，因为它正在帮你守住 React 状态管理的底线。

好了，今天的讲座就到这里。希望大家在写代码的时候，能想象那个指针正在你的 AST 骨架上一步步地移动。保持顺序，保持敬畏！

谢谢大家！