React useReducer 归约逻辑：探究在 render 阶段如何多次调用 reducer 以计算最终状态快照 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位好！欢迎来到今天的“React 内部机制深度解剖”特别讲座。

今天我们要聊的，不是那个只会写 console.log 的新手，也不是那个只会把 CSS 写成 !important 的老手。我们要聊的是 React 的基石——useReducer。尤其是它那个让人又爱又恨的“脾气”：在渲染阶段，它可能会被调用很多次，直到把那个“最终状态快照”给算出来为止。

我知道，听到“渲染阶段”和“多次调用”这几个词，你的头皮可能已经有点发麻了。别怕，咱们今天把这层窗户纸捅破。我会用最通俗、最幽默（或者说最像吐槽大会）的方式，带你走进 React 的肚子，看看它是怎么把一个简单的 dispatch 变成一堆复杂的计算逻辑的。

准备好了吗？让我们开始吧。

第一章：useReducer 是什么？它不是魔法，是数学

首先，我们要给 useReducer 去魅。

很多人以为 useReducer 是 React 给我们发的一块魔法石，只要一扔，状态就变了。错！大错特错。

useReducer 本质上就是一个函数。一个纯粹的、不带感情的、像数学老师一样的函数。

它的签名长这样：

function reducer(state, action) {
  switch (action.type) {
    case 'INCREMENT':
      return { ...state, count: state.count + 1 };
    case 'DECREMENT':
      return { ...state, count: state.count - 1 };
    default:
      throw new Error('不认识的动作');
  }
}

你看，它接收两个参数：state（当前状态）和 action（你扔过去的那个动作）。然后，它必须返回一个新的 state。

就这么简单。没有副作用，没有网络请求，没有 DOM 操作。它就是一个纯函数。

那它跟 useState 有啥区别？
useState 就像是给纯函数加了个自动递增的计数器。你调用 dispatch，React 就帮你调用一次这个函数，然后更新 UI。
而 useReducer 是你自己控制这个计数器。你想让它加 1，你就扔 INCREMENT；你想让它减 10，你就扔 DECREMENT_10。它给了你更多的控制权，特别是在处理复杂的状态逻辑时。

第二章：渲染阶段——那个“不能回头”的舞台

现在，让我们把目光聚焦到 React 最核心、也最容易让人晕头转向的地方——渲染阶段。

想象一下，React 就是一个导演，而你的组件就是演员。导演喊“Action”，演员就开始演戏（渲染）。

在渲染阶段，React 会做两件事：

计算新的状态：这是我们的主题。
生成新的 JSX：也就是组件要显示的内容。

这两个动作是同步的。这意味着，从渲染阶段开始的那一刻，直到渲染结束，中间没有任何暂停，没有“下一帧”的概念。就像是你正在切菜，你不能突然停下来去喝口水，因为菜切完了，饭就凉了。

关键点来了：
在渲染阶段，React 非常严格。它不允许你做任何“改变外部世界”的事情。比如，你不能在渲染阶段直接调用 dispatch（除非你极度自信并且想体验生活）。

但是，React 允许你调用 reducer 函数。因为 reducer 是纯函数，不改变世界。

第三章：那个“多次调用”的谜团

现在，让我们进入正题。为什么 useReducer 会在渲染阶段被“多次调用”？

这通常发生在一种特殊的场景下：你把 dispatch 传给了子组件，而子组件在渲染期间调用了它。

让我们看一个经典的“递归渲染”代码示例：

import React, { useReducer } from 'react';

// 这是一个简单的计数器组件
const Counter = () => {
  const [state, dispatch] = useReducer((state, action) => {
    console.log('🚀 Reducer 被调用了！当前状态:', state.count, '动作:', action.type);

    switch (action.type) {
      case 'INCREMENT':
        // 假设我们有一个复杂的逻辑，比如只有当状态大于 5 时才增加
        // 或者更常见的：我们在 reducer 里直接 dispatch 了另一个 action
        // 注意：这通常是一个反模式，但能帮助我们理解原理
        if (state.count < 5) {
            return { ...state, count: state.count + 1 };
        }
        return state;
      default:
        return state;
    }
  }, { count: 0 });

  return (
    <div>
      <h1>当前计数: {state.count}</h1>
      {/* 这里把 dispatch 传给了子组件 */}
      <ChildComponent onIncrement={() => dispatch({ type: 'INCREMENT' })} />
    </div>
  );
};

// 子组件
const ChildComponent = ({ onIncrement }) => {
  console.log('👶 子组件正在渲染...');
  return (
    <button onClick={onIncrement}>
      +1 (我在渲染期间被点击了)
    </button>
  );
};

场景模拟：

第一次渲染：
- React 开始渲染 Counter。
- state 初始是 { count: 0 }。
- React 调用 reducer 计算状态。控制台输出：🚀 Reducer 被调用了！当前状态: 0。
- Reducer 返回 { count: 0 }（因为没满足条件）。
- Counter 返回 JSX。JSX 里包含了 <ChildComponent onIncrement={...} />。
- React 开始渲染 ChildComponent。
第二次渲染（就在第一次渲染的“同一帧”里）：
- 等等，React 还没结束第一次渲染呢！
- ChildComponent 在渲染。它生成了 JSX。
- 它的 onClick 属性里绑定了 onIncrement。
- 关键点来了：虽然 ChildComponent 还没被挂载到 DOM 上，但它的 onClick 已经被 React 捕获了。
- 当用户点击按钮（假设用户点击了），React 会触发 onIncrement。
- onIncrement 调用了 dispatch({ type: 'INCREMENT' })。
第三次渲染（仍在第一次渲染周期内）：
- React 意识到：“哎呀，我在渲染期间收到了一个状态更新请求！”
- React 不会停下来等用户点击，也不会等到下一次 requestAnimationFrame。它必须在当前这个渲染周期内把这个更新处理完。
- React 再次调用 reducer。
- 控制台输出：🚀 Reducer 被调用了！当前状态: 0 动作: INCREMENT。
- Reducer 返回 { count: 1 }。
第四次渲染（计算快照）：
- React 发现状态变了（从 0 变成了 1），所以它需要重新渲染 Counter。
- 控制台输出：🚀 Reducer 被调用了！当前状态: 1 动作: INCREMENT。
- Reducer 返回 { count: 2 }。

结论：
在同一个渲染周期内，reducer 可能被调用了 3 次。为什么？因为 React 必须把所有的 dispatch（动作）都收集起来，计算出一个最终的 state，然后才能决定“好了，渲染结束，把 DOM 换掉”。

第四章：那个神奇的“Pending State”与“快照”

你可能会问：“React 哥，你刚才说 reducer 调用了 3 次，那最后 UI 上显示的是多少？是 0？1？还是 2？”

答案是：最终显示的是最后一次 reducer 返回的状态快照。

为了实现这个“多次调用但最终只有一个结果”的魔法，React 内部维护了一个 pendingState（待定状态）。

当你在渲染期间调用 dispatch 时，React 并不会立即更新组件的 state。它只是把这个 action 放进一个队列里。

// React 内部伪代码逻辑（简化版）
function render() {
  let currentState = initialPendingState;

  // 1. 处理当前组件的 dispatch
  if (currentComponentDispatchQueue.length > 0) {
    currentComponentDispatchQueue.forEach(action => {
      // 这里多次调用 reducer
      currentState = reducer(currentState, action); 
    });
  }

  // 2. 计算完所有动作后，得到了最终的快照
  const finalState = currentState;

  // 3. 用这个快照去渲染 UI
  return <UI based on finalState />;
}

这就是所谓的状态快照。它就像是一张照片。不管你在渲染过程中怎么折腾，怎么调用 reducer，只要照片拍下来（渲染结束），那就是定格的。

举个更生动的例子：

想象你在做一个三明治。

初始状态：只有一片面包。
动作 1：你扔进去一片生菜。
动作 2：你扔进去一片火腿。
动作 3：你盖上另一片面包。

这个过程就是“多次调用 reducer”。虽然你在做三明治的过程中，每一秒都在往里面加料，但当你切开盘子递给朋友的那一刻，你给他的就是一个完整的、最终的三明治快照。

第五章：副作用与渲染的“赛跑”

这是最危险的地方。也是让无数新手掉头发的地方。

如果你在渲染期间调用 dispatch，然后你的组件里有一个 useEffect 依赖了这个 state，会发生什么？

const BadComponent = () => {
  const [state, dispatch] = useReducer(reducer, 0);

  useEffect(() => {
    console.log('useEffect 触发了！状态是:', state.count);
  }, [state.count]); // 依赖项是 state.count

  return <button onClick={() => dispatch({ type: 'INC' })}>+1</button>;
};

运行流程：

渲染开始：state.count 是 0。useEffect 的依赖检查通过（虽然它还没执行）。JSX 生成。
用户点击：dispatch({ type: 'INC' }) 被调用。
Reducer 被调用：count 变成 1。
渲染结束：React 决定更新 DOM。此时 state.count 是 1。
Effect 触发：React 把 useEffect 的回调函数扔进队列。

等等，React 哥，不是说了渲染是同步的吗？Effect 不是在渲染之后吗？

没错！Effect 绝对不会在渲染期间触发。 它是“渲染结束后的下一个阶段”。

所以，当你点击按钮时，React 会：

在渲染期间多次调用 Reducer（为了计算快照）。
然后更新 DOM。
然后执行 useEffect。

结果： useEffect 里的日志会打印 状态是: 1。

这看起来没问题？是的，看起来没问题。但如果逻辑更复杂一点呢？

复杂场景：

const ComplexComponent = () => {
  const [state, dispatch] = useReducer((state, action) => {
    if (action.type === 'SYNC') {
      // 在 reducer 里直接 dispatch
      dispatch({ type: 'ADD_ONE' }); 
      return { ...state, count: state.count + 1 };
    }
    return state;
  }, { count: 0 });

  return <button onClick={() => dispatch({ type: 'SYNC' })}>同步增加</button>;
};

如果你点击这个按钮，reducer 会调用 dispatch({ type: 'ADD_ONE' })。
这会导致无限循环吗？
不会。React 会阻止这种情况。如果你在渲染期间 dispatch，React 会报错或者限制这种行为（取决于具体的 React 版本和配置）。

但如果你在 reducer 里调用 dispatch，并且这个 dispatch 触发了组件的重新渲染，而这个重新渲染又触发了原来的 dispatch… 哎呀，那就死循环了。

所以，记住这条铁律：

永远不要在渲染期间调用 dispatch！

这就像你不能在切菜的时候再去切菜。你只能在菜切完了之后，把切好的菜端上桌。

第六章：如何优雅地处理“多次调用”

既然我们知道 reducer 可能会被多次调用，我们该如何优化代码，避免它跑得太快把 CPU 烧了，或者逻辑太乱把自己绕晕呢？

1. 利用 `useMemo` 和 `useCallback`

如果你的 reducer 逻辑非常复杂，涉及大量的计算、排序或者遍历，那么每次调用 dispatch 都重新计算一遍可能会很慢。

const ExpensiveReducer = ({ data }) => {
  const [state, dispatch] = useReducer((state, action) => {
    // 这里有一个昂贵的计算
    const sortedData = useMemo(() => data.sort((a, b) => a.val - b.val), [data]);
    // ...处理逻辑
  }, { ... });

  return <div>...</div>;
};

虽然 React 会在渲染期间多次调用 reducer，但它也会尽可能复用计算结果。不过，最好的办法是把昂贵的计算移到 useMemo 里，或者干脆不要在渲染期间触发 dispatch。

2. 拆分逻辑

如果你的 reducer 逻辑太长，导致在渲染期间调用多次时，代码可读性下降，那就拆分它。

function reducer(state, action) {
  switch (action.type) {
    case 'SET_USER': 
      return handleSetUser(state, action.payload); // 调用辅助函数
    case 'SET_THEME':
      return handleSetTheme(state, action.payload);
    default:
      return state;
  }
}

3. 使用 `startTransition` (React 18+)

这是 React 18 带来的大杀器，专门用来解决“渲染期间 dispatch 导致卡顿”的问题。

默认情况下，所有的状态更新都是紧急的。如果你在渲染期间 dispatch，它就是紧急的，必须立即完成。

但有了 startTransition，你可以告诉 React：“嘿，这个更新不急，你可以慢慢来。”

import { startTransition } from 'react';

function SearchComponent() {
  const [query, setQuery] = useState('');
  const [results, dispatch] = useReducer(reducer, []);

  const handleChange = (e) => {
    const value = e.target.value;
    setQuery(value); // 这个更新是紧急的（比如输入框的文本）

    startTransition(() => {
      // 这个更新是非紧急的（比如搜索结果）
      dispatch({ type: 'SEARCH', payload: value });
    });
  };
}

在这个例子中，dispatch({ type: 'SEARCH' }) 不会阻塞输入框的响应。React 会在后台慢慢计算那个“最终状态快照”，而不会让用户的打字体验卡顿。

第七章：实战演练——构建一个“手风琴”组件

为了彻底搞懂这个机制，我们来写一个稍微复杂点的组件：一个手风琴。它有多个面板，每个面板可以展开或折叠。

痛点：
通常我们会用 useState 来存展开的面板 ID。但如果用 useReducer，我们可以更优雅地管理“展开”和“折叠”的逻辑。

const Accordion = () => {
  // 初始状态：没有面板展开
  const [state, dispatch] = useReducer((state, action) => {
    console.log(`🔄 Reducer: 处理动作 ${action.type}, 当前状态: ${state.openPanels.join(',')}`);

    switch (action.type) {
      case 'TOGGLE_PANEL':
        // 如果面板已经打开，就关闭；如果关闭，就打开
        // 注意：这里我们直接返回新数组，这是不可变数据更新
        if (state.openPanels.includes(action.payload)) {
          return {
            ...state,
            openPanels: state.openPanels.filter(id => id !== action.payload)
          };
        } else {
          return {
            ...state,
            openPanels: [...state.openPanels, action.payload]
          };
        }

      case 'RESET_ALL':
        return { ...state, openPanels: [] };

      default:
        return state;
    }
  }, { openPanels: [] });

  return (
    <div>
      <button onClick={() => dispatch({ type: 'RESET_ALL' })}>重置所有</button>
      <div className="accordion">
        {['面板 A', '面板 B', '面板 C'].map((title, index) => (
          <Panel 
            key={index} 
            id={index} 
            title={title} 
            isOpen={state.openPanels.includes(index)}
            onToggle={() => dispatch({ type: 'TOGGLE_PANEL', payload: index })}
          />
        ))}
      </div>
    </div>
  );
};

const Panel = ({ title, isOpen, onToggle }) => {
  // 这里 isOpen 是一个布尔值，来自 reducer 的计算结果
  return (
    <div className={`panel ${isOpen ? 'open' : 'closed'}`}>
      <div className="header" onClick={onToggle}>
        {title} {isOpen ? '▼' : '▶'}
      </div>
      {isOpen && <div className="content">这里是 {title} 的内容...</div>}
    </div>
  );
};

观察：
当你点击“重置所有”时，dispatch({ type: 'RESET_ALL' }) 被调用。
React 会：

调用 Reducer。Reducer 返回 { openPanels: [] }。
检查 state.openPanels 从 [0, 1] 变成了 []。状态变了！
触发重新渲染。
重新调用 Reducer（因为状态变了）。
返回 []。
再次检查。状态没变。
渲染结束。

在这个例子中，Reducer 被调用了 2 次。第一次是为了响应你的点击，第二次是为了验证更新是否成功。这就是计算最终状态快照的过程。

第八章：总结——如何驾驭这只猛兽

好了，朋友们，我们今天从 useReducer 的基本定义聊到了渲染阶段的多次调用，再到状态快照的计算，最后还讲了副作用和并发模式。

让我们回顾一下核心要点：

Reducer 是纯函数：它只负责数学计算，不负责副作用。
渲染阶段是同步的：在这个阶段，React 会把所有的 dispatch 收集起来，多次调用 reducer，直到算出最终的那个“快照”。
不要在渲染期间 Dispatch：这是铁律。如果你在渲染期间 dispatch，会导致额外的渲染周期，虽然 React 会帮你管理，但这会让你的代码变得难以预测。
Effect 不在渲染期间执行：即使你在渲染期间 dispatch 导致状态变了，useEffect 也会在渲染结束后才执行，此时它看到的已经是“新状态”了。
利用 startTransition：如果你真的需要在渲染期间做大量状态更新，记得用 startTransition 把它标记为非紧急任务。

React 的设计哲学就是“声明式”和“可预测”。useReducer 通过将状态逻辑封装在 reducer 函数里，让 React 更容易地协调状态更新。

当你理解了“渲染阶段多次调用 reducer”这个机制，你就不再是 React 的一个“使用者”，而是一个“架构师”。你开始明白，为什么某些代码会报错，为什么某些性能优化是必须的，以及为什么 React 能在浏览器里跑得那么溜。

所以，下次当你写 useReducer 的时候，请记住：你不仅仅是在写一个函数，你是在指挥一场精密的交响乐。而 dispatch 就是乐谱上的音符，reducer 是指挥家，而 render 阶段，就是那激动人心的演奏时刻。

好了，今天的讲座就到这里。希望大家在未来的 React 开发中，能够游刃有余地驾驭 useReducer，写出既漂亮又高效的代码！

（掌声响起… 虽然这里没有真的掌声，但请想象一下）