面试题：React 的‘纯组件’（PureComponent）与‘纯函数’（Pure Function）在 Fiber 协调算法中的待遇差异

各位同仁，下午好！

今天，我们将深入探讨 React 世界中两个看似相似却在底层机制，尤其是在 Fiber 协调算法中拥有截然不同待遇的概念：React 的‘纯组件’（PureComponent/React.memo）与‘纯函数’（Pure Function）。理解它们之间的差异，对于我们构建高性能、可维护的 React 应用至关重要。我们将以 Fiber 协调算法为核心，剖析这两种“纯”在 React 内部是如何被处理的。

一、 Fiber 协调算法：React 性能的基石

在深入探讨“纯”之前，我们首先需要对 React 的核心协调算法——Fiber，有一个清晰的认识。Fiber 是 React 16 引入的全新协调引擎，它彻底改变了 React 内部处理组件树的方式，旨在提供更流畅、更响应的用户体验。

1.1 为什么需要 Fiber？

在 Fiber 之前，React 的协调（reconciliation）过程是同步且不可中断的。这意味着一旦组件开始渲染，它就必须一口气完成整个组件树的遍历和更新，直到所有变更都被计算出来。这个过程会阻塞主线程，导致在大型应用或复杂更新时，UI 出现卡顿、不响应的情况。

Fiber 的核心目标就是解决这个问题。它将协调过程拆分成可中断、可恢复的“工作单元”（work unit），这些工作单元可以被暂停、恢复或甚至丢弃。这使得 React 能够：

• 增量渲染 (Incremental Rendering): 将渲染工作分散到多个帧中。
• 暂停和恢复工作 (Pause and Resume): 优先处理用户交互等高优先级任务。
• 任务优先级 (Prioritization): 对不同类型的更新赋予不同的优先级。
• 并发模式 (Concurrent Mode): 最终目标，允许 React 在后台同时处理多个任务。

1.2 Fiber 的核心工作流程

Fiber 算法大致可以分为两个主要阶段：渲染/协调阶段 (Render/Reconciliation Phase) 和 提交阶段 (Commit Phase)。

• 渲染阶段 (Render Phase):

  • 这个阶段是“可中断”的。React 会遍历组件树，执行组件的 render 方法（对于类组件）或函数体（对于函数组件），并计算出需要进行的 DOM 变更。
  • 它会构建一个“工作中的树”（Work-In-Progress tree），这是一个新的 Fiber 树，代表了组件的最新状态。
  • 在这个阶段，React 不会进行任何实际的 DOM 操作。它只是进行计算和标记。
  • 主要的任务是 beginWork 和 completeWork：
    • beginWork: 处理当前 Fiber 节点，创建子 Fiber 节点。
    • completeWork: 处理当前 Fiber 节点及其子节点，向上冒泡收集副作用（如 DOM 更新、生命周期方法调用）。
  • 如果在这个阶段 React 检测到有更高优先级的任务，它会暂停当前工作，将控制权交还给浏览器，并在稍后恢复。

• 提交阶段 (Commit Phase):

  • 这个阶段是“不可中断”的。一旦渲染阶段计算出所有变更，提交阶段会一次性地将这些变更应用到真实的 DOM 上。
  • 这包括 DOM 的创建、更新、删除，以及调用生命周期方法（如 componentDidMount, componentDidUpdate, useEffect 的清理和执行）。
  • 由于这个阶段会直接修改 DOM，因此必须是同步且不可中断的，以避免 UI 不一致。

1.3 Fiber 节点 (Fiber Node)

Fiber 树是由 Fiber 节点组成的。每个 Fiber 节点代表一个组件实例、一个 DOM 元素或一个文本节点。它包含了组件的类型、状态、props、指向父/子/兄弟 Fiber 的指针，以及最重要的——当前组件在整个更新过程中的状态和标记。这些标记（flags）告诉 Fiber 调度器需要对该节点执行哪些操作（如 Placement, Update, Deletion 等）。

理解 Fiber 的这些基本概念，是理解 PureComponent 和纯函数在其中待遇差异的基础。

二、 “纯”的含义：编程范式与 React 上下文

在讨论 Fiber 如何处理它们之前，我们首先要明确“纯”在不同语境下的含义。

2.1 纯函数 (Pure Function)

纯函数是函数式编程的核心概念。一个函数被称为纯函数，必须满足两个条件：

1. 相同的输入，总是产生相同的输出 (Deterministic): 给定相同的输入参数，纯函数总是返回相同的结果。它不依赖于任何外部可变状态，也不受外部状态变化的影响。
2. 无副作用 (No Side Effects): 纯函数不会修改任何外部状态，也不会执行任何可观察到的副作用。副作用包括但不限于：
   • 修改全局变量或闭包变量。
   • 修改传入的参数对象。
   • 网络请求（AJAX）。
   • DOM 操作。
   • 文件 I/O。
   • 打印到控制台（虽然通常认为这是弱副作用，但在严格的纯函数定义中也应避免）。

纯函数的优点：

• 可预测性 (Predictability): 结果总是可预测的，易于理解。
• 可测试性 (Testability): 独立于外部环境，易于编写单元测试。
• 可缓存性 (Cacheability): 由于相同的输入总是产生相同的输出，其结果可以被缓存（memoization）。
• 可并行性 (Parallelizability): 多个纯函数可以在没有数据竞争的情况下并行执行。

在 React 中的应用：

• 函数组件 (Functional Components): 理想情况下，函数组件在不依赖 useState, useEffect 等 Hook 时，可以被视为纯函数。当它们只接收 props 并返回 JSX 时，如果 props 相同，输出的 JSX 结构也应该相同。
• Reducers: 在 useReducer 或 Redux 中，reducer 函数必须是纯函数。
• 工具函数: 许多辅助函数，如数据转换、格式化等，都应该被设计成纯函数。

示例：纯函数

// 这是一个纯函数
function sum(a, b) {
  return a + b;
}

// 这不是一个纯函数，因为它依赖外部变量
let total = 0;
function addToTotal(num) {
  total += num; // 副作用：修改外部状态
  return total;
}

// 这也不是一个纯函数，因为它修改了传入的参数
function addToArray(arr, item) {
  arr.push(item); // 副作用：修改传入的参数
  return arr;
}

// 这是一个纯函数版本的 addToArray
function addToArrayPure(arr, item) {
  return [...arr, item]; // 返回新数组，不修改原数组
}

2.2 React PureComponent / React.memo

React.PureComponent 是一个基类，它扩展了 React.Component 并自动实现了 shouldComponentUpdate 方法。这个 shouldComponentUpdate 方法会对组件的 props 和 state 进行浅层比较 (shallow comparison)。

• 如果浅层比较发现 props 和 state 都没有发生变化，那么 shouldComponentUpdate 会返回 false，阻止组件及其子树的重新渲染。
• 如果发现有任何变化，则返回 true，允许组件继续渲染。

对于函数组件，我们使用 React.memo 来实现类似的功能。React.memo 是一个高阶组件 (Higher-Order Component, HOC)，它包裹一个函数组件，并对其 props 进行浅层比较。

PureComponent / React.memo 的目标：

它们的目标非常明确——性能优化。通过避免不必要的组件渲染和其子树的协调，从而减少 Fiber 协调算法的工作量，提升应用的响应速度。

示例：PureComponent 与 React.memo

import React, { Component } from 'react';

// PureComponent 示例
class MyPureComponent extends PureComponent {
  render() {
    console.log('MyPureComponent renders', this.props.value);
    return (
      <div>
        <h2>Pure Component: {this.props.value}</h2>
        <p>Data: {this.props.data.count}</p>
      </div>
    );
  }
}

// React.memo 示例
const MyMemoComponent = React.memo(function MyMemoComponent(props) {
  console.log('MyMemoComponent renders', props.value);
  return (
    <div>
      <h2>Memo Component: {props.value}</h2>
      <p>Data: {props.data.count}</p>
    </div>
  );
});

// 父组件
class ParentComponent extends Component {
  state = {
    count: 0,
    obj: { value: 10 },
    data: { count: 0 }
  };

  componentDidMount() {
    setInterval(() => {
      this.setState(prevState => ({
        count: prevState.count + 1,
        // obj: { ...prevState.obj, value: prevState.obj.value + 1 }, // 每次都创建新对象
        // data: { ...prevState.data, count: prevState.data.count + 1 } // 每次都创建新对象
      }));
    }, 1000);
  }

  // 模拟一个不会改变的引用，以展示 PureComponent/memo 的效果
  // 如果这里直接写 { count: this.state.count }，MyPureComponent 和 MyMemoComponent 也会重新渲染
  // 因为每次 render 都会创建一个新的对象字面量 { count: ... }，导致浅比较失败
  get memoizedData() {
    return { count: this.state.data.count };
  }

  render() {
    console.log('ParentComponent renders');
    return (
      <div>
        <h1>Parent Component (Count: {this.state.count})</h1>
        {/*
          当 this.state.obj 不变时，MyPureComponent 不会重新渲染
          如果 obj 每次都创建新对象，即使值不变，也会重新渲染
        */}
        <MyPureComponent value={this.state.obj.value} data={this.state.data} />

        {/*
          当 props.value 和 props.data 浅比较不变时，MyMemoComponent 不会重新渲染
          注意：如果 data 每次都创建新对象，即使内部值不变，也会重新渲染
          这里为了演示浅比较，我们传入 this.state.data，当 data 引用不变时，不会渲染
        */}
        <MyMemoComponent value={this.state.obj.value} data={this.state.data} />

        {/* 
          如果 MyMemoComponent 依赖一个函数 prop，且该函数每次都是新创建的，
          即使其他 props 不变，也会导致 MyMemoComponent 重新渲染。
          这需要结合 useCallback 进行优化。
        */}
        <MyMemoComponentWithFunction
          value={this.state.obj.value}
          onClick={() => console.log('clicked')} // 每次 render 都会创建新函数
        />
      </div>
    );
  }
}

const MyMemoComponentWithFunction = React.memo(function MyMemoComponentWithFunction(props) {
  console.log('MyMemoComponentWithFunction renders', props.value);
  return (
    <button onClick={props.onClick}>
      Memo Component with Function Prop: {props.value}
    </button>
  );
});

关键区别总结：

特征	纯函数 (Pure Function)	PureComponent / React.memo
定义	编程范式，指函数行为（无副作用，确定性）	React 提供的特定组件类型/HOC，用于性能优化
目的	提高代码的可预测性、可测试性、可维护性	避免不必要的组件渲染和其子树的协调，提升渲染性能
作用范围	任何 JavaScript 函数，不限于 React 组件	仅限于 React 组件（类组件或函数组件）
“纯”的衡量	函数内部逻辑是否满足无副作用和确定性	组件的 props 和 state（浅层）是否发生变化
性能影响	间接影响，通过减少错误、提高代码质量和可缓存性	直接影响，通过跳过 Fiber 协调算法中的渲染阶段

三、 PureComponent / React.memo 在 Fiber 中的待遇

现在，我们聚焦到核心问题：Fiber 协调算法是如何对待 PureComponent 和 React.memo 的？

3.1 核心机制：浅层比较与跳过子树

当 Fiber 算法在渲染阶段遍历组件树时，遇到 PureComponent 或 React.memo 包裹的函数组件时，会触发一个特殊的检查流程。

1. Fiber 节点类型识别： Fiber 调度器会识别当前处理的 Fiber 节点的类型。如果它是一个 ClassComponent 并且其 shouldComponentUpdate 方法被重写（PureComponent 会自动重写），或者它是一个 FunctionComponent 并且 memoizedProps 存在（React.memo 会设置），Fiber 就会知道这是一个“纯”的组件。

2. 执行浅层比较：

   • 对于 PureComponent，Fiber 会调用其内置的 shouldComponentUpdate 方法。这个方法会比较 nextProps 与 this.props，以及 nextState 与 this.state。比较是浅层的，即只比较引用地址。
   • 对于 React.memo，Fiber 会比较 nextProps 与 prevProps。同样，这也是浅层的比较。React.memo 还可以接受第二个参数 arePropsEqual，允许开发者自定义比较逻辑，但默认行为是浅层比较。

3. Fiber 的决策：

   • 如果浅层比较结果为 true (表示 props 和 state 发生了变化)： Fiber 认为组件需要更新。它会像处理普通组件一样，继续执行该组件的 render 方法（或函数体），并递归地协调其子组件树。
   • 如果浅层比较结果为 false (表示 props 和 state 没有变化)： 这是 PureComponent 和 React.memo 发挥作用的关键时刻。Fiber 会认为这个组件不需要重新渲染。此时，它会执行以下优化：
     • 跳过 render 方法/函数体执行： 组件的 render 方法或函数体将不会被调用。
     • 跳过子树的协调： 更重要的是，Fiber 会完全跳过对该组件所有子 Fiber 节点的协调工作。它会直接从当前的 Fiber 树（current tree）中克隆（clone）对应的子树到工作中的 Fiber 树（work-in-progress tree）。这意味着整个子树的 beginWork 和 completeWork 过程都被避免了。
     • 标记为 NoUpdate： 该 Fiber 节点会被标记为 NoUpdate，表示它及其子树在提交阶段不需要进行任何 DOM 操作。

3.2 代码示例：PureComponent / React.memo 的效果

让我们通过一个具体的例子来观察 PureComponent 和 React.memo 如何影响 Fiber 的协调过程。

import React, { Component, PureComponent, useState, useCallback } from 'react';

// 普通函数组件
const NormalChild = ({ value, obj }) => {
  console.log('  NormalChild renders', value);
  return <p>Normal Child: {value} (Obj count: {obj.count})</p>;
};

// PureComponent 子组件
class PureChild extends PureComponent {
  render() {
    console.log('  PureChild renders', this.props.value);
    return <p>Pure Child: {this.props.value} (Obj count: {this.props.obj.count})</p>;
  }
}

// React.memo 子组件
const MemoChild = React.memo(({ value, obj, onClick }) => {
  console.log('  MemoChild renders', value);
  return (
    <div>
      <p>Memo Child: {value} (Obj count: {obj.count})</p>
      <button onClick={onClick}>Click Me</button>
    </div>
  );
});

function App() {
  const [parentCount, setParentCount] = useState(0);
  const [objData, setObjData] = useState({ count: 0 }); // 引用稳定的对象
  const [unstableObj, setUnstableObj] = useState({ count: 0 }); // 引用不稳定的对象

  // 模拟父组件的频繁更新
  // 每秒更新 parentCount
  React.useEffect(() => {
    const interval = setInterval(() => {
      setParentCount(prev => prev + 1);
      // 每次都创建一个新对象，导致 PureComponent/MemoChild 的浅比较失败
      setUnstableObj({ count: prev => prev + 1}); // 每次都创建新对象
    }, 1000);
    return () => clearInterval(interval);
  }, []);

  // 模拟一个稳定引用，用于展示 PureComponent/MemoChild 的优化效果
  const stableObj = React.useMemo(() => ({ count: 100 }), []);

  // 模拟一个稳定函数引用，用于展示 MemoChild 结合 useCallback 的优化效果
  const handleClick = useCallback(() => {
    console.log('Button clicked!');
  }, []);

  console.log('App renders', parentCount);

  return (
    <div>
      <h1>Parent Component (App): {parentCount}</h1>

      <hr />
      <h3>普通组件 (NormalChild)</h3>
      {/*
        NormalChild 每次都会重新渲染，因为它没有实现 shouldComponentUpdate
        即使 props.value 和 props.obj 的引用没有改变，只要父组件 App 重新渲染，它就会渲染
      */}
      <NormalChild value={parentCount % 5} obj={stableObj} />
      <NormalChild value={parentCount % 5} obj={unstableObj} />

      <hr />
      <h3>PureComponent 组件 (PureChild)</h3>
      {/*
        PureChild 只有在 props.value 或 props.obj 的引用发生变化时才会重新渲染。
        这里的 stableObj 引用始终不变，所以当 parentCount 变化时，如果 value 值不变，PureChild 不会渲染
      */}
      <PureChild value={parentCount % 5} obj={stableObj} />

      {/*
        注意：如果传入的对象引用每次都变化，即使内部值相同，PureComponent 也会重新渲染
        这里 unstableObj 每次都是新对象，所以 PureChild 每次都会渲染
      */}
      <PureChild value={parentCount % 5} obj={unstableObj} />

      <hr />
      <h3>React.memo 组件 (MemoChild)</h3>
      {/*
        MemoChild 行为与 PureChild 类似。当 value 和 obj 引用不变时，不会渲染。
        这里的 stableObj 引用始终不变，所以当 parentCount 变化时，如果 value 值不变，MemoChild 不会渲染
        handleClick 使用了 useCallback 保持引用稳定。
      */}
      <MemoChild value={parentCount % 5} obj={stableObj} onClick={handleClick} />

      {/*
        同样，如果传入的对象引用每次都变化，MemoChild 也会重新渲染
        这里的 unstableObj 每次都是新对象，所以 MemoChild 每次都会渲染
      */}
      <MemoChild value={parentCount % 5} obj={unstableObj} onClick={handleClick} />
    </div>
  );
}

export default App;

运行上述代码，你会观察到以下现象：

1. App renders 每秒都会打印，因为 parentCount 状态在变化。
2. NormalChild renders 每次 App 渲染时都会打印，因为它没有优化机制。
3. PureChild renders 和 MemoChild renders：
   • 当传入 stableObj 且 value (parentCount % 5) 的值在连续的渲染中没有变化时，它们不会打印。这表明 Fiber 成功跳过了这些组件的渲染。
   • 当 value 变化时，它们会打印。
   • 当传入 unstableObj 时，即使 value 可能没有变，它们也会打印，因为 unstableObj 的引用每次都在变化，导致浅比较失败。
   • MemoChild 结合 useCallback 确保 onClick 函数引用稳定，否则即使其他 props 不变，如果 onClick 每次都是新函数，MemoChild 也会重新渲染。

3.3 PureComponent / React.memo 的优点与局限性

优点：

• 显著提升性能： 通过避免不必要的渲染和子树协调，极大地减少了 Fiber 的工作量，尤其是在复杂组件树中，效果显著。
• 简化优化逻辑： 自动处理 shouldComponentUpdate 的浅层比较，开发者无需手动编写。

局限性/陷阱：

• 浅层比较的限制： 这是最常见的陷阱。如果 props 或 state 中包含引用类型（对象、数组、函数），而这些引用类型在内容发生变化时，其引用地址却没有变化（例如，直接修改原数组而不是返回新数组），PureComponent 或 memo 将无法检测到变化，导致组件不会更新。反之，如果每次渲染都创建一个新的对象或数组字面量，即使其内容与之前完全相同，引用地址也会变化，导致浅比较失败，组件不必要的重新渲染。
  • 解决方案： 始终使用不可变数据结构。在更新对象或数组时，总是创建新的实例（如使用扩展运算符 ... 或 map, filter 等方法）。对于函数，使用 useCallback。
• context 的影响： useContext Hook 或 Context.Consumer 可能会绕过 React.memo 的优化。当 Context 值发生变化时，所有订阅该 Context 的组件（即使被 memo 包裹）都会重新渲染。
  • 解决方案： 拆分组件，将依赖 Context 的部分放在一个非 memo 组件中，或者在 memo 组件的 arePropsEqual 中处理 Context 相关逻辑（这通常比较复杂）。
• 性能开销： 浅层比较本身也有成本。如果组件的 props 和 state 频繁变化，或者组件数量非常庞大，频繁的浅比较开销可能抵消其带来的益处，甚至可能引入负优化。因此，需要结合性能分析工具来决定是否使用。
• children Prop： 如果 children 是一个 JSX 元素，它的引用通常是稳定的。但如果 children 是一个函数或一个复杂对象，其引用变化可能导致 memo 失效。

四、 纯函数在 Fiber 中的待遇

现在，我们转向纯函数。一个纯函数，作为一种编程范式，它在 Fiber 协调算法中得到的待遇与 PureComponent / React.memo 有着本质的区别。

4.1 纯函数作为组件的 Fiber 待遇

当一个函数组件被定义为纯函数（即它的输出完全由其 props 决定，且内部无副作用，不使用 useState 等 Hooks），但没有被 React.memo 包裹时，Fiber 算法是如何处理它的呢？

1. 无特殊优化标记： Fiber 调度器不会像处理 PureComponent 或 React.memo 那样，为它设置特殊的优化标记。
2. 父组件渲染即子组件渲染： 如果父组件重新渲染（无论是普通组件还是 PureComponent 因为 props 变化而渲染），那么它的所有子函数组件（包括那些本身是纯函数的组件）都会重新执行其函数体。
3. 执行函数体并协调子代： Fiber 会执行这个函数组件的函数体，获取其返回的 JSX 元素。然后，它会根据这个 JSX 元素，继续递归地协调其子组件。

换句话说，纯函数组件（未 memo 化）本身并不能阻止 Fiber 执行其渲染阶段的工作。 它的“纯度”体现在其行为的可预测性上，而非在 React 协调算法层面的跳过渲染。

示例：普通纯函数组件的 Fiber 待遇

import React, { useState } from 'react';

// 这是一个纯函数组件，它的输出只依赖于 props.name 和 props.age
// 但它没有被 React.memo 包裹
const PureFunctionalComponent = ({ name, age }) => {
  console.log(`  PureFunctionalComponent renders: ${name}, ${age}`);
  // 假设这里进行了一些复杂的纯计算，返回一个计算结果
  const greeting = `Hello, ${name}! You are ${age} years old.`;
  return <p>{greeting}</p>;
};

// 这是一个使用纯函数工具的组件
const DisplayCalculation = ({ num1, num2 }) => {
  console.log(`  DisplayCalculation renders: ${num1}, ${num2}`);
  const result = multiply(num1, num2); // 调用纯函数工具
  return <p>Calculation: {num1} * {num2} = {result}</p>;
};

// 纯函数工具
function multiply(a, b) {
  console.log('    Executing pure utility function: multiply');
  return a * b;
}

function App() {
  const [count, setCount] = useState(0);
  const [personName, setPersonName] = useState('Alice');

  React.useEffect(() => {
    const interval = setInterval(() => {
      setCount(prev => prev + 1);
      // 假设 personName 偶尔变化，但大部分时间不变
      if (count % 3 === 0) {
        setPersonName('Bob');
      } else {
        setPersonName('Alice');
      }
    }, 1000);
    return () => clearInterval(interval);
  }, [count]);

  console.log('App renders', count);

  return (
    <div>
      <h1>Parent Component (App): {count}</h1>

      <hr />
      <h3>普通纯函数组件 (PureFunctionalComponent)</h3>
      {/*
        即使 props.name 和 props.age 没有变化，只要 App 渲染，
        PureFunctionalComponent 也会重新渲染。
        它的“纯”体现在函数内部的逻辑，而非阻止渲染。
      */}
      <PureFunctionalComponent name={personName} age={30} />
      <PureFunctionalComponent name="Charlie" age={25} /> {/* 这个组件的props是稳定的 */}

      <hr />
      <h3>使用纯函数工具的组件 (DisplayCalculation)</h3>
      {/*
        DisplayCalculation 每次 App 渲染都会重新渲染。
        内部的 multiply 纯函数会每次都被调用。
        纯函数本身不阻止组件渲染。
      */}
      <DisplayCalculation num1={5} num2={count % 10} />
      <DisplayCalculation num1={10} num2={20} /> {/* num1, num2 稳定，但组件仍会渲染 */}
    </div>
  );
}

export default App;

观察结果：

1. App renders 每秒打印。
2. PureFunctionalComponent renders 每次 App 渲染时都会打印，即使 name 和 age 的值（例如 Charlie, 25）在很多次渲染中是相同的。
3. DisplayCalculation renders 每次 App 渲染时都会打印。
4. Executing pure utility function: multiply 也会每次 DisplayCalculation 渲染时都打印，即使 num1 和 num2 的值（例如 10, 20）是稳定的。

这清晰地表明，纯函数本身的特性并不能在 Fiber 层面提供自动的渲染跳过优化。

4.2 纯函数作为工具函数在 Fiber 中的待遇

当纯函数作为组件内部的辅助函数或工具函数被调用时，Fiber 算法并不会对其有任何特殊的处理。

1. 只是普通 JavaScript 执行： 在组件的 render 方法或函数体执行期间，当遇到对纯函数的调用时，Fiber 仅仅是让 JavaScript 引擎执行这个函数。
2. 无 Fiber 优化： Fiber 不会检查这个工具函数是否“纯”，也不会因为它的纯度而跳过任何工作。
3. 潜在的性能影响： 如果这个纯函数执行了非常昂贵的计算，并且它在每次组件渲染时都被调用，那么即使组件的其他部分没有变化，这个昂贵的计算也会被重复执行，造成性能浪费。

4.3 纯函数的优点与局限性

优点：

• 代码质量： 提高代码的可读性、可维护性和可测试性。
• 可预测性： 保证在任何情况下，给定相同的输入，函数总是返回相同的结果。
• 间接性能优化： 纯函数的确定性和无副作用特性，使其非常适合与 React.useMemo 或 React.useCallback 结合使用，从而间接地为 Fiber 提供优化机会。

局限性：

• 不提供直接的 React 渲染优化： 纯函数本身不具备 PureComponent 或 React.memo 那样的机制来告诉 Fiber 调度器跳过组件的渲染。
• 需要手动缓存： 如果纯函数执行昂贵计算，开发者需要手动使用 useMemo 或其他缓存机制来避免重复计算。

五、 核心差异与 Fiber 视角的对比分析

为了更清晰地对比 PureComponent / React.memo 和纯函数在 Fiber 协调算法中的待遇差异，我们用一个表格来总结：

特征/方面	PureComponent / React.memo	纯函数 (作为组件或工具函数)
“纯”的定义	React 性能优化机制，基于 props 和 state 的浅层比较。	编程范式，指函数行为的确定性和无副作用。
核心目标	避免不必要的组件渲染和子树协调，提升 React 渲染性能。	提高代码的可预测性、可测试性、可维护性。
Fiber 协调阶段	直接影响 Fiber 渲染阶段的决策。	不直接影响 Fiber 渲染阶段的决策。
Fiber 如何处理	1. 识别特殊类型： 调度器识别出 PureComponent 或 React.memo。 2. 执行浅层比较： 比较 props 和 state（或 props）。 3. 跳过子树协调： 如果浅比较通过，Fiber 会将当前 Fiber 节点的 child 指针直接指向旧 Fiber 树的对应子节点，并标记为 NoUpdate，完全跳过该组件及其子树的 render 方法执行和子 Fiber 协调过程。	1. 只是普通组件或函数： Fiber 调度器将其视为普通函数组件或代码块。 2. 执行函数体： 如果父组件渲染，该函数组件的函数体会被执行。如果作为工具函数，在组件 render 期间被调用。 3. 继续协调子代： 即使函数是纯的，Fiber 也会继续协调其返回的 JSX 子代（除非子代是 memo 化且 props 稳定）。 纯函数本身不提供跳过机制。
性能优化方式	自动的、声明式的渲染跳过优化。	间接的，通过代码质量和潜在的 useMemo / useCallback 手动缓存来优化。
关注点	React 内部的渲染效率。	通用编程的逻辑正确性和可维护性。
潜在问题	浅比较陷阱（引用类型问题）、context 绕过。	无法自动避免重复渲染或重复昂贵计算。

从 Fiber 的视角来看，PureComponent 和 React.memo 是其内部调度器可以直接理解和利用的“信号”。这些信号告诉 Fiber：“嘿，这个组件可能不需要重新渲染，去检查一下它的 props 和 state。如果没变，就跳过它下面的所有工作！” 这是一种主动的、声明式的性能优化策略。

而纯函数，尽管其内部逻辑是“纯”的，对于 Fiber 调度器来说，它只是一个普通的 JavaScript 函数。Fiber 不会对其进行特殊检查，也不会因为它的纯度而自动跳过任何渲染工作。开发者需要通过其他手段（如 React.memo 结合 useCallback/useMemo）才能将纯函数的特性转化为 Fiber 可识别的性能优化信号。

六、 实践中的结合与权衡：优化 React 应用

理解了这些差异，我们就能更明智地在实际开发中运用它们来优化 React 应用。

6.1 PureComponent / React.memo 的使用场景

• 性能瓶颈识别： 只有当你通过 React DevTools 的 Profiler 发现某个组件确实是渲染性能瓶颈时，才考虑使用 PureComponent 或 React.memo。过度使用可能导致不必要的浅比较开销。
• 稳定且频繁更新的父组件： 当一个组件的父组件频繁更新，但该组件自身的 props 和 state 却相对稳定时，PureComponent / React.memo 能发挥最大作用。
• 复杂的子树： 如果组件的子树非常庞大且渲染成本高昂，那么阻止该组件渲染就能带来巨大的性能提升。
• 配合不可变数据： 必须配合不可变数据结构使用。任何对对象或数组的修改都应该返回新的引用。

6.2 纯函数的应用与 useMemo / useCallback 的桥接

• 构建可靠的业务逻辑： 始终优先将业务逻辑编写为纯函数，以提高代码质量。

• 函数组件的默认选择： 大多数函数组件应该首先作为普通函数组件来编写。只有当出现性能问题时，再考虑 React.memo。

• useMemo 缓存昂贵计算： 如果组件内部有昂贵的纯函数计算，可以使用 useMemo 来缓存其结果，避免在每次渲染时重复计算。

  const MyComponent = ({ list }) => {
    // 假设 calculateExpensiveResult 是一个纯函数
    const expensiveResult = React.useMemo(() => calculateExpensiveResult(list), [list]);
    return <div>Result: {expensiveResult}</div>;
  };

• useCallback 稳定函数引用： 当一个 memo 化的子组件接收一个函数作为 prop 时，为了防止父组件重新渲染时导致该函数引用变化而使子组件重新渲染，可以使用 useCallback 来稳定函数引用。

  const Parent = () => {
    const [count, setCount] = useState(0);
  
    // 使用 useCallback 确保 handleClick 的引用在 count 变化时不改变
    const handleClick = useCallback(() => {
      console.log('Button clicked, count is:', count);
    }, [count]); // 依赖 count，当 count 变化时，handleClick 引用会更新
  
    return (
      <div>
        <button onClick={() => setCount(count + 1)}>Increment Parent</button>
        <MemoChild value={count} onClick={handleClick} />
      </div>
    );
  };
  
  const MemoChild = React.memo(({ value, onClick }) => {
    console.log('  MemoChild renders');
    return (
      <div>
        <p>Child Value: {value}</p>
        <button onClick={onClick}>Click Child Button</button>
      </div>
    );
  });

6.3 Context API 与 memo 的注意事项

useContext 会导致组件在 Context 值发生变化时重新渲染，这会绕过 React.memo 的浅比较。

• 解决方案：
  1. 拆分组件： 将消费 Context 的部分与需要 memo 化的部分拆开，让 Context 消费者成为一个较小的、独立的组件。
  2. 选择性 Context： 确保 Context 提供的值是稳定的，或者只包含真正需要变化的部分。
  3. React.memo 的第二个参数： 可以为 React.memo 提供一个自定义的 arePropsEqual 函数，以更精细地控制何时重新渲染，但通常不推荐，因为它增加了复杂性。

6.4 不可变数据结构的重要性

无论是 PureComponent 还是 React.memo，它们的核心都依赖于浅层比较。因此，使用不可变数据结构是发挥其优化作用的基石。当你更新数据时，总是创建数据的副本，而不是直接修改原始数据。

// 错误示例：直接修改对象，导致引用不变，PureComponent/memo 无法检测变化
const originalObj = { a: 1, b: 2 };
originalObj.a = 3; // 引用不变

// 正确示例：创建新对象，引用变化，PureComponent/memo 可以检测变化
const originalObj = { a: 1, b: 2 };
const newObj = { ...originalObj, a: 3 }; // 创建新对象

七、 深入理解 shallowEqual

PureComponent 和 React.memo 内部使用的浅层比较函数通常称为 shallowEqual。其基本原理是：

1. 比较引用： 检查两个对象或数组的引用是否完全相同（===）。
2. 比较属性数量： 如果引用不同，则检查它们的属性数量是否相同。
3. 比较属性值： 遍历所有属性，检查对应属性的值是否通过 === 严格相等。

function shallowEqual(objA, objB) {
  if (objA === objB) {
    return true;
  }

  if (typeof objA !== 'object' || objA === null || typeof objB !== 'object' || objB === null) {
    return false;
  }

  const keysA = Object.keys(objA);
  const keysB = Object.keys(objB);

  if (keysA.length !== keysB.length) {
    return false;
  }

  for (let i = 0; i < keysA.length; i++) {
    const key = keysA[i];
    if (!Object.prototype.hasOwnProperty.call(objB, key) || objA[key] !== objB[key]) {
      return false;
    }
  }

  return true;
}

这个 shallowEqual 函数正是 Fiber 在 PureComponent 或 React.memo 节点上做出“是否跳过”决策的依据。

八、 总结性的思考

React 的 PureComponent (或 React.memo) 和纯函数，尽管都带有“纯”字，但在 Fiber 协调算法中的地位和待遇却截然不同。

PureComponent 和 React.memo 是 React 特有的渲染性能优化机制。它们通过对 props 和 state 进行浅层比较，为 Fiber 调度器提供了一个明确的信号：如果组件的输入没有发生变化，就可以直接跳过整个组件子树的协调工作，从而显著减少渲染开销。这是对 Fiber 算法执行路径的直接干预和优化。

而纯函数则是一种通用的编程范式，强调函数的确定性和无副作用。它主要提升代码的可预测性、可测试性和可维护性。纯函数本身并不能直接告诉 Fiber 调度器跳过组件的渲染。如果一个函数组件是纯的但未被 memo 化，或者一个纯工具函数在组件内部被调用，它们仍然会在父组件重新渲染时被执行。其性能优势更多体现在与 useMemo 和 useCallback 等 Hooks 结合使用时，通过缓存计算结果或稳定函数引用，间接为 memo 化组件创造跳过渲染的条件。

理解这两者在 Fiber 协调算法中的差异，能帮助我们更精准地识别性能瓶颈，并选择最恰当的优化策略。通过合理地使用 React.memo、useCallback、useMemo，并结合不可变数据结构和纯函数的编程实践，我们可以构建出既高性能又易于维护的健壮 React 应用。