React useReducer 的状态归约稳定性：探究在并发重渲染下 reducer 多次执行后的幂等性保证 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同学，大家下午好！

欢迎来到今天的“React 并发模式与状态归约稳定性”深度研讨会。我是你们的主讲人，一个在代码世界里摸爬滚打多年，看着 useState 变成 useReducer，看着 useEffect 变得“并发”的资深工程师。

今天我们要聊的话题，听起来可能有点枯燥，甚至有点像数学课本里的内容——“状态归约的稳定性”，特别是那个听起来像绕口令一样的词——“幂等性”。

别急着划走，别急着把手机扔一边。我知道，“幂等性”这个词听起来像是在描述一种只有数学系高材生才能理解的神秘咒语。但今天，我要告诉大家，这不仅仅是数学，这是 React 并发模式下的生存法则。如果你不懂这个，当你面对 React 18 的并发渲染时，你的应用可能会像一只被踩了尾巴的猫，疯狂地闪烁、重置、报错。

我们今天的任务只有一个：搞清楚为什么你的 reducer 函数必须是“纯洁”的，以及为什么在并发重渲染下，它必须表现得像个“复读机”。

第一部分：什么是“幂等性”？（别被名字吓到了）

在深入代码之前，我们先来定义一下什么是“幂等性”。

在数学和计算机科学中，如果一个函数 $f(x)$ 满足 $f(f(x)) = f(x)$，那么它就是幂等的。简单来说，不管你调用这个函数一次、两次、一百次，只要输入是一样的，输出就绝对一样。

在 React 的 useReducer 上下文中，这意味着什么？

这意味着你的 reducer(state, action) 函数必须是一个纯函数。

想象一下，你有一个收银员（Reducer）。顾客（Action）来了，收银员计算价格。如果收银员是“幂等”的，那么不管顾客进来一百次，还是收银员被打断了一次，回来又重新算了一遍，最后给顾客的收据（State）必须是完全一致的。

如果收银员不是幂等的，比如他喝醉了，第一次算给 100 块，第二次因为心情不好算给了 200 块，那么在 React 并发模式下，这就是一场灾难。

第二部分：并发渲染的“疯狂”现实

为什么我们需要强调幂等性？因为 React 18 引入了并发渲染。

以前，React 像是一个只会按部就班的流水线工人。你给我一个指令（渲染），我执行到底，中间不许打断。但现在，React 变成了一个“多任务操作系统”。

想象一下，你正在写一个复杂的表单。你疯狂点击“提交”按钮，或者你触发了多个状态更新。在旧版本中，React 会把所有更新排队，一个一个处理。

但在并发模式下，React 会停下来。它可能会说：“哎呀，这个更新太重了，我先暂停一下，处理一下用户的键盘输入，或者处理一下浏览器的其他任务。” 然后它回来，继续处理刚才的更新。

这就带来了一个核心问题：在一个渲染周期内，Reducer 可能会被多次调用。

场景模拟：

假设你有一个计数器，点击一下加 1。

// 普通的 reducer
function reducer(state, action) {
  if (action.type === 'INCREMENT') {
    return { count: state.count + 1 };
  }
  return state;
}

如果 React 在处理 INCREMENT 的时候，因为某种原因（比如父组件重渲染导致子组件重渲染）被中断了，然后又重新开始处理 INCREMENT。

对于上面的 reducer，无论调用多少次，结果都是对的：count 加 1。

但是，如果你的 reducer 里有一行代码：

function reducer(state, action) {
  if (action.type === 'WEIRD_TRICK') {
    // 这是一个不纯的操作！
    return { count: state.count + Math.random() };
  }
  return state;
}

这就完了。第一次调用，Math.random() 返回 0.5，count 变成了 10.5。第二次调用，Math.random() 可能返回 0.9，count 变成了 11.4。

注意！ 这里的 count 是数字，不是对象。10.5 + 0.5 和 10.5 + 0.9 是完全不同的值。React 根本不知道你中间偷偷改了主意，它只会认为最新的状态是 11.4。

第三部分：隐形杀手——副作用与上下文

除了 Math.random() 这种明显的作弊行为，还有更隐蔽的杀手：副作用和Context。

在 useReducer 的 reducer 函数内部，绝对不能做任何副操作。

1. 禁止在 Reducer 中使用 `useEffect`、`console.log` 或网络请求

这听起来像废话，但很多人会犯这个错。他们觉得：“我在 reducer 里打印个日志调试一下嘛，反正不影响逻辑。”

错！大错特错！

在并发模式下，如果你在 reducer 里放了一个 console.log，或者更糟糕的，一个 console.error（如果你忘了 try-catch），React 的渲染过程会被打断。

React 的渲染过程是同步的。如果 reducer 执行了同步代码（比如 console.log），React 必须等待它完成。如果 console.log 触发了某些副作用，或者如果 console.error 被捕获并导致错误边界重新渲染，整个渲染树就会崩溃。

function reducer(state, action) {
  if (action.type === 'MAGIC') {
    // 千万别这么做！
    console.log('Debugging state'); 

    // 如果这里抛出异常，整个组件树都会停止渲染
    fetch('/api/data'); 

    return { ...state };
  }
  return state;
}

2. 禁止在 Reducer 中读取 Context

这可能是最容易被忽视的一点。

const ThemeContext = React.createContext('dark');

function reducer(state, action) {
  if (action.type === 'TOGGLE') {
    // 危险！
    const theme = useContext(ThemeContext); 

    // 依赖外部上下文的状态
    return { ...state, theme: theme === 'dark' ? 'light' : 'dark' };
  }
  return state;
}

为什么？因为 useContext 的值依赖于组件树中最近的 Provider。在并发渲染中，组件树的结构可能会被暂时移除或改变（比如 Suspense 边界）。如果你在 reducer 里读 Context，你读到的可能是一个“幽灵”值，或者导致 Context 重新计算，进而触发更多的渲染，形成死循环。

第四部分：函数引用的稳定性

这是 useReducer 中最容易让人头疼的地方：dispatch 函数的引用稳定性。

当你使用 useReducer 时，你会得到一个 dispatch 函数。

const [state, dispatch] = useReducer(reducer, initialState);

如果你把 dispatch 传给子组件，或者作为依赖项放在 useEffect 里，你必须确保它每次渲染都是同一个引用。

function Parent() {
  const [state, dispatch] = useReducer(reducer, initialState);

  // 错误示范：每次都创建一个新的 reducer 函数
  function reducer(state, action) {
    return { ...state, value: action.value };
  }

  return <Child dispatch={dispatch} />;
}

在错误示范中，reducer 函数每次 Parent 组件渲染时都会被重新创建。React 会认为这是一个新的 reducer。

虽然 React 18 做了一些优化，但在某些边缘情况下，如果 reducer 不稳定，可能会导致 React 无法正确地合并状态更新，或者导致状态初始化逻辑被意外触发。

正确的做法：

将 reducer 提取到组件外部（最推荐）。
使用 useCallback。

// 1. 提取到外部
const myReducer = (state, action) => { ... };

function Parent() {
  const [state, dispatch] = useReducer(myReducer, initialState);
  return <Child dispatch={dispatch} />;
}

第五部分：深度不可变性与并发

让我们来点硬核的。useReducer 要求状态更新必须返回一个新的状态对象。这不仅仅是风格问题，这是 React 并发模式能够工作的物理基础。

并发模式的核心原理：

React 使用一种叫做“可变更新队列”的技术。当你在渲染期间调用 dispatch 时，React 不会立即更新状态。它会把这次更新加入队列。

但是，为了实现“中断渲染”和“重置渲染”，React 需要能够回滚状态。

如果使用的是可变更新（例如 state.items.push(item)），React 就无法回滚。因为 push 修改了原数组。如果 React 中断了渲染，它无法简单地把数组“撤回”到修改前的状态。

代码示例：突变 vs 不可变

// 坏习惯：可变更新
function reducer(state, action) {
  if (action.type === 'ADD_ITEM') {
    state.items.push(action.item); // 直接修改原数组
    return state; // 返回了同一个引用！
  }
  return state;
}

// 好习惯：不可变更新
function reducer(state, action) {
  if (action.type === 'ADD_ITEM') {
    return {
      ...state,
      items: [...state.items, action.item] // 创建新数组
    };
  }
  return state;
}

在并发模式下，如果使用了第一种方式（可变），当你中断渲染并重新开始渲染时，你的数据结构可能已经被污染了。你可能会得到一个长度为 2 的数组，但实际上你只添加了一个元素。或者，更糟糕的是，你在同一个渲染周期内添加了两个元素，但最后只显示了一个，因为 React “忘记”了第二次更新。

为什么 ...state 和 [...arr] 如此重要？

因为它们创建了新的引用。React 可以清楚地分辨出“旧的 State”和“新的 State”。当并发渲染中断时，React 可以直接丢弃新的 State，重新使用旧的 State，而不会破坏数据的完整性。

第六部分：实战演练——那个“幽灵”点击事件

让我们构建一个真实的场景，来演示为什么稳定性如此重要。

场景： 一个购物车，用户疯狂点击“添加商品”。

import React, { useReducer, useCallback } from 'react';

// 定义初始状态
const initialState = {
  items: [],
  total: 0,
  loading: false,
};

// 定义 Reducer
// 注意：这是一个纯函数，没有副作用，没有随机数，没有 Context
function cartReducer(state, action) {
  switch (action.type) {
    case 'ADD_ITEM':
      return {
        ...state,
        items: [...state.items, action.payload],
        total: state.total + action.payload.price,
      };
    case 'REMOVE_ITEM':
      return {
        ...state,
        items: state.items.filter(item => item.id !== action.payload),
        total: state.total - action.payload.price,
      };
    default:
      return state;
  }
}

// 购物车组件
function ShoppingCart() {
  const [state, dispatch] = useReducer(cartReducer, initialState);

  const handleAddItem = (item) => {
    // 这个函数每次渲染都会重新创建
    dispatch({ type: 'ADD_ITEM', payload: item });
  };

  return (
    <div className="cart">
      <h2>我的购物车</h2>
      <ul>
        {state.items.map(item => (
          <li key={item.id}>{item.name} - ${item.price}</li>
        ))}
      </ul>
      <div>总计: ${state.total}</div>
      <button onClick={() => handleAddItem({ id: 1, name: '苹果', price: 5 })}>
        添加苹果
      </button>
    </div>
  );
}

问题出在哪里？

handleAddItem 函数。每次 ShoppingCart 组件重新渲染（比如 items 数组变了，或者 total 变了），handleAddItem 都会是一个全新的函数。

虽然在这个简单的例子中，它可能还能正常工作（因为 dispatch 本身通常会被 React 优化），但在复杂的组件树中，如果子组件使用了 useCallback 并依赖 handleAddItem，这会导致子组件无休止地重新渲染。

修复方案：

function ShoppingCart() {
  const [state, dispatch] = useReducer(cartReducer, initialState);

  // 使用 useCallback 稳定 dispatch 函数
  const dispatch = useCallback((action) => {
    // 这里其实可以加一些逻辑，比如日志，但绝对不能有副作用
    console.log('Dispatching:', action.type);
    // 调用原始的 dispatch
    // 注意：这里我们利用 useReducer 返回的 dispatch
  }, []); // 空依赖数组，因为 reducer 是外部的

  // 或者，更简单的方法，直接把 reducer 提取出去
  // const [state, dispatch] = useReducer(cartReducer, initialState);

  const handleAddItem = useCallback((item) => {
    dispatch({ type: 'ADD_ITEM', payload: item });
  }, [dispatch]);

  // ...
}

等等，上面的代码有个小误区。useReducer 返回的 dispatch 本身是稳定的（在同一个 reducer 实例下）。问题通常出在reducer 函数本身不稳定，或者你把 reducer 定义在组件内部。

终极建议：

把 reducer 定义在组件外部。这是最简单、最有效的保证稳定性的方法。

// 文件顶部
function cartReducer(state, action) { ... }

// 组件内部
function ShoppingCart() {
  const [state, dispatch] = useReducer(cartReducer, initialState);
  // ...
}

第七部分：深入探究——为什么 React 要这么做？

你可能会问：“老师，如果 React 18 现在这么智能，能不能自动处理这些不稳定的情况？”

答案是：不能。或者说，不能在不牺牲性能或正确性的前提下处理。

React 的并发模式依赖于“可中断”的渲染。

如果 reducer 函数内部有副作用（比如读取 Context），React 就无法安全地中断渲染。因为一旦中断，Context 的读取可能会失效，或者导致 Context 的更新逻辑被破坏。

如果 reducer 函数是可变的，React 就无法回滚。因为数据结构已经被破坏了。

React 必须依赖开发者编写“纯”的 reducer。这是契约。如果你签了这个契约，React 就会给你并发渲染的加速和更好的用户体验。如果你违约了，React 只能把你扔进“旧模式”的坑里，或者直接报错。

第八部分：总结——如何写出“安全”的 Reducer

好了，讲了这么多，我们来总结一下如何写出在并发模式下坚如磐石的 Reducer 函数。

纯函数是底线： 输入相同，输出必须绝对相同。不要依赖时间、随机数、外部变量。
禁止副作用： 不要在 reducer 里做网络请求、DOM 操作、打印日志（除非是调试环境）、读取 Context。
不可变数据： 始终返回一个新的 state 对象和新的数组对象。使用展开运算符 ...。不要修改 state 的属性或数组元素。
Reducer 的位置： 把 reducer 函数定义在组件外部，或者使用 useCallback 包装。不要把它放在组件内部。
Dispatch 的稳定性： 确保 dispatch 函数的引用是稳定的。如果 reducer 是外部的，dispatch 自然是稳定的。

第九部分：一个极端的例子——递归 Reducer 的陷阱

最后，我们来玩个刺激的。递归 Reducer。

假设我们有一个嵌套的状态结构，我们需要在一个深层的数据结构中找到某个节点并更新它。

function reducer(state, action) {
  if (action.type === 'UPDATE_NODE') {
    // 递归查找并更新
    const findAndUpdate = (node) => {
      if (node.id === action.payload.id) {
        return { ...node, value: action.payload.value };
      }
      return {
        ...node,
        children: node.children.map(findAndUpdate)
      };
    };

    return {
      ...state,
      tree: findAndUpdate(state.tree)
    };
  }
  return state;
}

这个 reducer 看起来很完美，对吧？它不可变，它纯。

但是，在并发模式下，这可能是性能杀手。

如果 state.tree 非常大（比如一个包含 1000 个节点的文件树），每次 dispatch 都会触发递归遍历。在并发渲染中，React 可能会多次调用这个 reducer。

这意味着你的文件树会被遍历 10 次，而不是 1 次。

优化方案：

不要在 reducer 里做深度的数据遍历。让 reducer 只负责修改“顶层”的状态，然后触发一个副作用（比如 useEffect）去处理深度的数据更新。

function reducer(state, action) {
  if (action.type === 'UPDATE_NODE') {
    // 只修改顶层状态
    return {
      ...state,
      // 标记需要更新
      dirty: true,
      pendingUpdate: action.payload
    };
  }
  return state;
}

// 在 useEffect 中处理深度更新
function useDeepUpdate(state) {
  useEffect(() => {
    if (state.dirty) {
      // 深度更新逻辑
      console.log('Performing deep update for:', state.pendingUpdate);
      // 更新完成后，重置 dirty 标记
      // ...
    }
  }, [state.dirty, state.pendingUpdate]);
}

为什么这样做？

因为 useEffect 是在渲染之后运行的。它不会被并发渲染打断（或者至少，它不会影响渲染本身的性能）。通过把昂贵的计算从渲染路径中剥离出来，我们保证了 reducer 的极速响应，同时完成了复杂的工作。

结语：拥抱纯度

各位同学，React 的并发模式是一场革命，它允许我们构建更流畅、更响应式的用户界面。但是，这场革命建立在“纯度”的基石之上。

useReducer 的稳定性，不仅仅是一个代码风格的问题，它是 React 能够安全地中断和恢复渲染的前提。

所以，当你下一次写 useReducer 的时候，请像对待一位严谨的数学家一样对待它。不要给它喂垃圾（副作用），不要给它喝醉（随机数），不要让它去修改私有财产（可变状态）。

保持它的纯度，保持它的幂等性，并发模式就会回报给你流畅丝滑的体验。

谢谢大家！现在，让我们拿起键盘，写出最纯净的 reducer 吧！