发布于 由admin

并发渲染中的“双重渲染”陷阱：为什么严格模式（Strict Mode）下组件会渲染两次？

各位开发者，欢迎来到今天的技术讲座。今天我们将深入探讨一个在React社区中经常引起困惑、甚至被误解的现象——在严格模式（Strict Mode）下，组件为什么会进行“双重渲染”（double rendering）。这并非React的缺陷，而是一个精心设计的、极其强大的诊断工具，它与React未来的并发渲染（Concurrent Rendering）架构紧密相连。

我们将从现象入手，逐步剖析其背后的原理、它所暴露的潜在问题，以及我们作为开发者应该如何应对，从而编写出更健壮、更具前瞻性的React应用。

1. 现象：组件渲染了两次？

让我们从一个简单的React组件开始。如果你在现代React开发环境（如create-react-app或Next.js）中创建一个新项目，默认情况下，你的应用会包裹在<React.StrictMode>中。现在，我们创建一个基本的组件，并在其渲染时和副作用执行时打印日志。

// src/components/MyStrictComponent.jsx
import React, { useState, useEffect } from 'react';

function MyStrictComponent() {
  console.log('--- MyStrictComponent render ---'); // 渲染时打印

  const [count, setCount] = useState(0);

  // 模拟一个副作用，例如订阅或事件监听
  useEffect(() => {
    console.log('MyStrictComponent: useEffect 运行了 (订阅)');
    const intervalId = setInterval(() => {
      // 模拟一些后台活动
      // console.log('MyStrictComponent: Interval ticking...');
    }, 1000);

    // 返回清理函数
    return () => {
      console.log('MyStrictComponent: useEffect 清理了 (取消订阅)');
      clearInterval(intervalId);
    };
  }, []); // 空依赖数组，表示只在组件挂载和卸载时运行一次效果及清理

  // 模拟另一个副作用，在每次count变化时运行
  useEffect(() => {
    console.log(`MyStrictComponent: count 变更为 ${count}`);
  }, [count]); // 依赖count

  const handleClick = () => {
    setCount(prevCount => prevCount + 1);
  };

  return (
    <div style={{ padding: '20px', border: '1px solid blue', margin: '20px' }}>
      <h2>Strict Mode 双重渲染演示</h2>
      <p>当前计数: {count}</p>
      <button onClick={handleClick}>增加计数</button>
      <p>请观察控制台输出。</p>
    </div>
  );
}

export default MyStrictComponent;

接着，在你的App.js或index.js中，确保你的组件被<React.StrictMode>包裹：

// src/App.js 或 src/index.js
import React from 'react';
import MyStrictComponent from './components/MyStrictComponent';

function App() {
  return (
    <React.StrictMode>
      <MyStrictComponent />
    </React.StrictMode>
  );
}

export default App;

当你运行这个应用并打开开发者工具的控制台时，你可能会看到类似以下的输出（顺序和具体行数可能略有不同，但关键点是重复）：

--- MyStrictComponent render ---
MyStrictComponent: useEffect 运行了 (订阅)
MyStrictComponent: count 变更为 0
--- MyStrictComponent render ---
MyStrictComponent: useEffect 清理了 (取消订阅)
MyStrictComponent: useEffect 运行了 (订阅)
MyStrictComponent: count 变更为 0

你可能感到惊讶：

  1. MyStrictComponent render 打印了两次。
  2. useEffect 的“订阅”部分也运行了两次。
  3. useEffect 的“清理”部分在第二次渲染前运行了一次。

这正是我们今天要探讨的“双重渲染”现象。初次接触时，许多开发者会认为这是一个Bug，或者担心它会导致性能问题。然而，这恰恰是React严格模式在开发环境中的一个有意为之的行为，目的是帮助我们编写更健壮的代码，以适应React未来的并发特性。

2. React的渲染机制：核心回顾

在深入探讨双重渲染之前，我们有必要快速回顾一下React的渲染机制。理解这些基础知识是理解双重渲染为何必要且安全的关键。

React的渲染过程可以大致分为两个阶段：

  1. 渲染阶段 (Render Phase)：

    • 在这个阶段，React会调用组件的函数体（对于函数组件）或render方法（对于类组件）。
    • 它根据组件的props和state计算出新的Virtual DOM树。
    • 这是一个纯计算过程，不应该产生任何副作用（如修改DOM、发起网络请求、更新外部状态等）。
    • 这个阶段可能被React暂停、中断、甚至重新开始多次，而不会对用户可见的UI产生影响。
    • React通过比较新旧Virtual DOM树来确定UI的哪些部分需要更新。

  2. 提交阶段 (Commit Phase)：

    • 在这个阶段，React会将渲染阶段计算出的Virtual DOM的变化实际应用到浏览器DOM上。
    • 这是唯一可以安全地产生副作用的阶段，例如：
      • 更新DOM。
      • 执行useEffect钩子中的逻辑（在所有DOM更新完成后）。
      • 执行类组件的生命周期方法如componentDidMount、componentDidUpdate、componentWillUnmount。
    • 一旦提交阶段开始，它将是同步的、不可中断的，以确保UI的一致性。

关键点在于：渲染阶段是纯粹的。 你的组件函数应该像一个纯函数一样，给定相同的props和state，总是返回相同的JSX（Virtual DOM）。它不应该有任何可观察到的副作用。如果渲染阶段产生了副作用，那么当React在并发模式下多次启动、暂停或重新开始渲染时，这些副作用可能会被多次触发，导致不一致的UI状态、数据泄露甚至应用崩溃。

3. 严格模式 (Strict Mode)：React的训练营

现在，我们来正式介绍严格模式。

3.1 什么是严格模式？

<React.StrictMode>是一个用于在开发环境中检测潜在问题的工具。它不会渲染任何可见的UI，也不会以任何方式影响生产构建。它只是为其内部的组件及其后代组件激活额外的检查和警告。

严格模式的根本目标是帮助你编写更健壮、更具前瞻性的代码，尤其是在React引入并发特性后。 它通过以下方式做到这一点：

  • 识别不安全的生命周期方法：警告使用过时的、容易导致问题的生命周期方法（如UNSAFE_componentWillMount）。
  • 检测旧版字符串ref用法：警告使用string ref而非回调ref或useRef。
  • 检测已弃用的旧版Context API：鼓励使用新的Context API。
  • 检测findDOMNode的使用：这是一个不推荐使用的直接访问DOM的方法。
  • 检测意外的副作用：这是我们今天的主题，通过双重渲染来暴露。
  • 检测state更新器函数中的不纯性：例如setState(updaterFunction)中的updaterFunction也应该是纯函数。

3.2 严格模式如何暴露意外的副作用？

这就是双重渲染发挥作用的地方。在开发环境中，严格模式会故意：

  1. 双重调用组件的渲染函数：组件函数（或类组件的render方法）会被调用两次。
  2. 双重调用useState、useMemo或useCallback的初始化函数/回调函数：这有助于发现这些函数中不纯的逻辑。
  3. 双重调用useEffect的设置函数，并在第二次调用前运行第一次的清理函数（如果存在）：这模拟了组件快速卸载和重新挂载，或者在并发模式下效果被“重置”的情景。

为什么这样做？

React的未来方向是并发模式，这意味着React可能在后台多次启动和暂停渲染工作，甚至可能在完成前丢弃它。如果你的渲染函数或某些生命周期/钩子函数中存在副作用，那么在并发模式下，这些副作用可能会被多次触发，或者在不完整的工作中触发，导致应用程序状态不一致。

严格模式的“双重渲染”行为，正是为了在开发阶段尽早地暴露这些不纯的、有副作用的代码。 它不是为了模拟两次独立的渲染，而是为了：

  • 测试渲染函数的纯度：如果你的渲染函数在第一次和第二次调用之间改变了任何外部状态或产生了可见的副作用，那么它就不是纯的。
  • 测试useEffect的清理机制：通过模拟快速的“挂载-卸载-挂载”循环（或者在某些情况下，仅仅是两次执行设置函数和一次清理），它确保你的useEffect能够正确地清理前一次的副作用，避免资源泄露或重复订阅。

简而言之，严格模式就像一个严厉的教练，它在训练中故意制造一些“困难”，来确保你的代码足够强壮，能够应对未来并发模式下的复杂场景。

4. 并发渲染 (Concurrent Rendering)：React的未来核心

要真正理解双重渲染的意义，我们必须将其置于React并发渲染的背景下。并发渲染是React架构演进的核心，旨在提升用户体验和应用的响应能力。

4.1 传统渲染 vs. 并发渲染

传统（阻塞式）渲染：
在React 18之前的版本中（或者说，在没有启用并发特性时），React的渲染更新是同步且阻塞的。一旦React开始处理一个更新，它会一口气完成所有组件的渲染和DOM更新，直到提交阶段结束。这意味着：

  • 如果更新工作量大，UI可能会卡顿，用户无法进行交互。
  • 高优先级的更新（如用户输入）可能会被低优先级的更新（如数据加载）阻塞。

并发渲染：
React 18引入了并发渲染，它允许React：

  • 中断渲染工作：如果React正在渲染一个组件树，但此时有更高优先级的更新（例如用户输入），React可以暂停当前低优先级的渲染工作，转而处理高优先级的更新。
  • 时间切片 (Time Slicing)：将大的渲染工作分解成小块，在每个小块之间，React可以检查是否有更高优先级的任务需要处理，或者将控制权交还给浏览器，避免长时间阻塞主线程。
  • 可丢弃的渲染结果：如果一个渲染工作被中断，并且之后发现它不再需要（例如，用户在数据加载完成前又点击了另一个按钮），React可以完全丢弃之前已完成的渲染工作，而不会将其提交到DOM。这意味着，一个组件的渲染函数可能被执行了一半就被放弃了。

4.2 并发渲染与双重渲染的深层联系

现在，核心问题来了：如果React可以随时中断、暂停、甚至丢弃渲染工作，那么组件的渲染函数（及其内部逻辑）必须是纯净且幂等的。

  • 纯净 (Pure)：渲染函数不应该有副作用。如果它在执行过程中修改了外部变量、发起了网络请求或直接操作了DOM，那么当渲染工作被丢弃时，这些副作用可能已经发生了，并且无法撤销。这会导致应用程序状态的不一致。
  • 幂等 (Idempotent)：一个操作是幂等的，意味着执行一次和执行多次会产生相同的结果。对于React组件的渲染而言，这意味着即使渲染函数被调用了两次、三次或更多次（因为被中断后重新开始），最终提交到DOM的UI状态也应该是一致的，而且不会产生额外的、意料之外的副作用。

严格模式的双重渲染，正是为了在开发环境中模拟并发模式下“可中断/可丢弃”的渲染行为。

  • 它通过两次调用渲染函数来检测你是否在渲染函数中执行了副作用。如果副作用发生两次，你就能立即发现。
  • 它通过运行useEffect的设置函数，然后立即运行清理函数，再运行设置函数，来模拟组件可能被“挂载-卸载-挂载”或“渲染-丢弃-重新渲染”的场景。这确保你的副作用逻辑（例如订阅、事件监听）能够正确地被清理，避免资源泄露。

总结来说，严格模式下的双重渲染，是React在开发环境中提供的一种“预警机制”，它强制开发者遵循纯函数和幂等性的原则，为未来React并发模式下更复杂的渲染调度做好准备。 它不是性能问题，而是一个强大的诊断工具。

5. "双重渲染"陷阱：识别与修复副作用

既然我们理解了双重渲染的原理，那么接下来就是最重要的部分：如何识别并修复那些可能被双重渲染暴露出来的潜在问题。这些问题通常来源于对React生命周期和副作用管理理解不足。

以下是一些常见的“陷阱”类型，以及它们在严格模式下如何暴露，以及正确的解决方案。

陷阱类型 典型代码示例 问题根源 严格模式下的暴露 解决方案
1. 渲染函数中直接的副作用 setState、fetch、DOM操作 破坏渲染纯度，导致无限循环或不一致 立即触发两次副作用，或导致无限循环 移至useEffect
2. useState初始化函数中的副作用 useState(expensiveComputation()) 重复执行昂贵操作，影响性能 初始化函数执行两次 使用useState(() => ...)惰性初始化
3. useMemo/useCallback中的副作用 useMemo(() => { console.log('...'); return val; }) 副作用被重复执行 回调函数执行两次 确保回调函数纯净，副作用移至useEffect
4. useEffect中缺少清理函数 useEffect(() => { subscribe(); }, []) 无return 资源泄露，多次注册，内存占用 两次useEffect运行，没有对应的清理导致泄露 提供return () => {}清理函数
5. useEffect依赖项不完整或不正确 useEffect(() => { fn(data); }, []) 但data在外部变化 闭包陷阱，使用过期变量，无法响应变化 严格模式不直接暴露，但会加剧问题 确保依赖项数组包含所有外部依赖

让我们逐一详细探讨这些陷阱。

5.1 陷阱1：渲染函数中直接的副作用

这是最常见的错误之一。渲染函数（组件的函数体）应该是一个纯函数，只负责根据props和state返回JSX。任何改变组件外部状态、发起网络请求、直接操作DOM等操作，都属于副作用，不应在此阶段执行。

错误示例：直接在渲染函数中修改状态或发起请求

import React, { useState } from 'react';

function BadRenderSideEffect() {
  console.log("BadRenderSideEffect rendered!");

  // ❌ 陷阱1a: 直接在渲染函数中修改状态
  // 这会导致无限渲染循环！每次渲染都会触发setState，setState又触发渲染。
  // const [count, setCount] = useState(0);
  // setCount(count + 1); // 绝对不能这样做！

  // ❌ 陷阱1b: 直接在渲染函数中发起网络请求
  // 每次渲染都会发起请求，导致网络风暴和数据不一致。
  // fetch('/api/data').then(response => response.json()).then(data => console.log(data));

  // ❌ 陷阱1c: 直接在渲染函数中执行高开销的计算且有副作用
  // 即使没有直接修改状态，如果这个计算影响了外部状态或DOM，也会有问题。
  const someExpensiveOperation = () => {
    console.log("执行了昂贵的计算，且可能包含副作用...");
    // 假设这里有某个全局变量被修改了，或直接操作了DOM
    // globalCounter++;
    return Math.random();
  };
  const result = someExpensiveOperation(); // 在渲染函数中被调用

  const [value, setValue] = useState(0);

  return (
    <div style={{ border: '1px solid red', margin: '10px', padding: '10px' }}>
      <h3>陷阱1: 渲染函数中的副作用</h3>
      <p>随机结果: {result}</p>
      <p>值: {value}</p>
      <button onClick={() => setValue(value + 1)}>更新值</button>
    </div>
  );
}

严格模式下的暴露：

  • 如果执行setCount(count + 1)，你会在控制台看到BadRenderSideEffect rendered!被无限打印，浏览器可能会崩溃。
  • 如果执行fetch，你会看到网络请求被发起两次（或更多次），或者在你的网络面板中看到大量的请求。
  • 如果执行someExpensiveOperation，其中的console.log会打印两次，明确指出其内部逻辑被执行了两次。如果它有实际的副作用，这些副作用也会发生两次，导致不一致。

解决方案：将副作用移至useEffect钩子

useEffect就是为副作用而生的。它在提交阶段运行，并且提供清理机制。

import React, { useState, useEffect } from 'react';

function GoodRenderSideEffect() {
  console.log("GoodRenderSideEffect rendered!");

  const [count, setCount] = useState(0);
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(false);

  // ✅ 正确做法: 使用 useEffect 发起网络请求
  useEffect(() => {
    console.log("useEffect: 正在发起网络请求...");
    setLoading(true);
    fetch('/api/data') // 假设这是一个有效的API端点
      .then(response => {
        if (!response.ok) {
          throw new Error('Network response was not ok');
        }
        return response.json();
      })
      .then(apiData => {
        setData(apiData);
        setLoading(false);
        console.log("useEffect: 网络请求完成。");
      })
      .catch(error => {
        console.error("useEffect: 网络请求失败:", error);
        setLoading(false);
      });

    // 如果网络请求可以取消，这里应返回一个清理函数
    // return () => { /* 取消请求操作 */ };
  }, []); // 空依赖数组，只在组件挂载时执行一次

  // ✅ 正确做法: 纯粹的渲染逻辑
  const expensivePureComputation = () => {
    console.log("执行了纯粹的昂贵计算...");
    return Math.sqrt(count * 123456789);
  };
  const result = expensivePureComputation();

  return (
    <div style={{ border: '1px solid green', margin: '10px', padding: '10px' }}>
      <h3>陷阱1修复: 渲染函数纯净</h3>
      <p>当前计数: {count}</p>
      <p>昂贵纯计算结果: {result}</p>
      <button onClick={() => setCount(count + 1)}>增加计数</button>
      {loading ? <p>加载数据中...</p> : <p>数据: {data ? JSON.stringify(data) : '无'}</p>}
    </div>
  );
}

注意： 如果/api/data不存在或无法访问，fetch会报错，但关键是它的调用位置。

5.2 陷阱2：useState初始化函数中的副作用

useState接受一个初始值。如果这个初始值需要通过昂贵的计算得到，你可以传入一个函数。React只会执行这个函数一次来获取初始值。但是，如果你直接调用了这个昂贵计算的函数，那么每次组件渲染时，这个函数都会被调用，即使它的返回值只在第一次渲染时被用作初始值。

错误示例：useState初始化函数中的昂贵计算

import React, { useState } from 'react';

function ExpensiveInitComponent() {
  const generateExpensiveValue = () => {
    console.log("❌ 陷阱2: 正在执行昂贵且可能多余的初始化计算...");
    let sum = 0;
    for (let i = 0; i < 100000000; i++) { // 模拟耗时操作
      sum += i;
    }
    return sum;
  };

  // ❌ 陷阱2: 直接调用函数作为初始值。每次组件渲染时都会执行 generateExpensiveValue
  const [value, setValue] = useState(generateExpensiveValue());

  return (
    <div style={{ border: '1px solid orange', margin: '10px', padding: '10px' }}>
      <h3>陷阱2: `useState`初始化副作用</h3>
      <p>计算结果: {value}</p>
      <button onClick={() => setValue(value + 1)}>更新值 (会再次触发昂贵计算)</button>
    </div>
  );
}

严格模式下的暴露：

当你初次加载组件时，"❌ 陷阱2: 正在执行昂贵且可能多余的初始化计算..." 会在控制台打印两次。这明确告诉你，你的昂贵计算被不必要地执行了两次。

解决方案：使用函数作为useState的初始值

当useState的初始值是一个函数时，React只会在组件首次渲染时执行该函数一次。

import React, { useState } from 'react';

function GoodExpensiveInitComponent() {
  const generateExpensiveValue = () => {
    console.log("✅ 陷阱2修复: 正在执行昂贵但只执行一次的初始化计算...");
    let sum = 0;
    for (let i = 0; i < 100000000; i++) {
      sum += i;
    }
    return sum;
  };

  // ✅ 正确做法: 传入一个函数作为初始值，React只会在首次渲染时调用它一次
  const [value, setValue] = useState(() => generateExpensiveValue());

  return (
    <div style={{ border: '1px solid green', margin: '10px', padding: '10px' }}>
      <h3>陷阱2修复: `useState`惰性初始化</h3>
      <p>计算结果: {value}</p>
      <button onClick={() => setValue(value + 1)}>更新值 (不会再次触发昂贵计算)</button>
    </div>
  );
}

5.3 陷阱3：useMemo或useCallback回调函数中的副作用

useMemo和useCallback用于性能优化，通过记忆化计算结果或函数实例来避免不必要的重新计算或重新创建。它们的本质是缓存，所以传入的回调函数也应该是纯函数，不应包含副作用。

错误示例：useMemo或useCallback回调函数中的副作用

import React, { useState, useMemo, useCallback } from 'react';

let globalCounter = 0;

function BadMemoCallbackSideEffect({ propA, propB }) {
  console.log("BadMemoCallbackSideEffect rendered!");

  // ❌ 陷阱3a: useMemo的回调函数中包含副作用
  const memoizedValue = useMemo(() => {
    console.log("❌ 陷阱3a: 正在计算记忆化值，且可能包含副作用...");
    globalCounter++; // 修改外部状态
    return propA + propB;
  }, [propA, propB]);

  // ❌ 陷阱3b: useCallback的回调函数创建时包含副作用
  const handleClick = useCallback(() => {
    console.log("按钮被点击了，globalCounter:", globalCounter);
    // 假设这个回调函数本身没有副作用，但其创建过程中有副作用
    // 如果这里有 side effect，那么在严格模式下，这个副作用可能会被模拟执行两次
    // 实际的useCallback只是创建函数实例，副作用通常在函数执行时发生。
    // 但如果副作用在函数体外部，即在创建函数时就已经发生，那就会有问题。
  }, []);

  return (
    <div style={{ border: '1px solid purple', margin: '10px', padding: '10px' }}>
      <h3>陷阱3: `useMemo`/`useCallback`副作用</h3>
      <p>记忆化值: {memoizedValue}</p>
      <p>全局计数器: {globalCounter}</p>
      <button onClick={handleClick}>点击我</button>
    </div>
  );
}

严格模式下的暴露：

在组件初次挂载时，"❌ 陷阱3a: 正在计算记忆化值，且可能包含副作用..." 会打印两次，globalCounter 会增加两次。这表明你的useMemo回调函数被执行了两次，其内部的副作用也发生了两次。

解决方案：确保回调函数纯净，副作用移至useEffect

useMemo和useCallback的回调函数只应该进行纯计算或返回纯函数。任何副作用都应该放在useEffect中。

import React, { useState, useMemo, useCallback, useEffect } from 'react';

let pureGlobalCounter = 0; // 这是一个不应该被渲染逻辑直接修改的外部变量

function GoodMemoCallbackSideEffect({ propA, propB }) {
  console.log("GoodMemoCallbackSideEffect rendered!");

  // ✅ 陷阱3修复: useMemo的回调函数是纯净的
  const memoizedValue = useMemo(() => {
    console.log("✅ 陷阱3修复: 正在计算记忆化值 (纯计算)...");
    return propA + propB;
  }, [propA, propB]);

  // ✅ 陷阱3修复: useCallback的回调函数是纯净的
  const handleClick = useCallback(() => {
    console.log("按钮被点击了，但其创建是纯净的。");
    // 如果点击后需要副作用，将其放在这里面，而不是在创建回调函数时
    // 比如：发送分析事件、修改状态等
  }, []);

  // 如果需要基于memoizedValue或propA/propB执行副作用，使用useEffect
  useEffect(() => {
    console.log("✅ 陷阱3修复: useEffect 执行副作用，基于memoizedValue:", memoizedValue);
    // 这里可以安全地修改外部状态或发起网络请求等
    pureGlobalCounter = memoizedValue; // 示例：将memoizedValue同步到外部
  }, [memoizedValue]); // 依赖memoizedValue

  return (
    <div style={{ border: '1px solid green', margin: '10px', padding: '10px' }}>
      <h3>陷阱3修复: `useMemo`/`useCallback`纯净</h3>
      <p>记忆化值: {memoizedValue}</p>
      <p>同步到外部的全局计数器 (通过useEffect): {pureGlobalCounter}</p>
      <button onClick={handleClick}>点击我</button>
    </div>
  );
}

5.4 陷阱4：useEffect中缺少清理函数

对于需要在组件卸载时进行清理的副作用（如订阅外部数据源、设置定时器、添加事件监听器等），useEffect的返回函数至关重要。如果缺少清理函数，或者清理逻辑不完整，会导致资源泄露、内存溢出或重复的副作用。

错误示例：useEffect中缺少清理函数

import React, { useEffect, useState } from 'react';

// 模拟一个外部服务，每次订阅会增加一个活动订阅计数
let activeSubscriptions = 0;

function subscribeToExternalService() {
  activeSubscriptions++;
  console.log(`❌ 陷阱4: 订阅外部服务。当前活动订阅: ${activeSubscriptions}`);
  return {
    unsubscribe: () => {
      activeSubscriptions--;
      console.log(`❌ 陷阱4: 取消订阅外部服务。当前活动订阅: ${activeSubscriptions}`);
    }
  };
}

function BadEffectCleanupComponent() {
  const [data, setData] = useState(0);

  useEffect(() => {
    const service = subscribeToExternalService();
    // 假设这里会处理service的数据更新
    const interval = setInterval(() => {
      setData(prev => prev + 1);
    }, 1000);

    // ❌ 陷阱4: 缺少清理函数！
    // 如果没有返回清理函数，那么 service 和 interval 就不会被清理
    // return () => {
    //   service.unsubscribe();
    //   clearInterval(interval);
    // };
  }, []); // 依赖数组为空，模拟只在挂载时订阅一次

  return (
    <div style={{ border: '1px solid brown', margin: '10px', padding: '10px' }}>
      <h3>陷阱4: `useEffect`缺少清理</h3>
      <p>数据: {data}</p>
      <p>请观察控制台的订阅计数。</p>
    </div>
  );
}

严格模式下的暴露：

当你初次加载组件时：

  1. "❌ 陷阱4: 订阅外部服务。当前活动订阅: 1"
  2. "❌ 陷阱4: 订阅外部服务。当前活动订阅: 2"

你将看到subscribeToExternalService被调用了两次，并且activeSubscriptions会变成2。这是因为严格模式模拟了快速的“挂载-卸载-挂载”循环：

  • 第一次useEffect运行，订阅1。
  • 严格模式触发清理（如果存在）。
  • 第二次useEffect运行，订阅2。

由于你的代码没有提供清理函数，第一次的订阅没有被取消，导致两次订阅都处于活动状态。这会导致资源泄露。

解决方案：始终提供正确的清理函数

对于任何需要清理的副作用，useEffect的回调函数应该返回一个清理函数。

import React, { useEffect, useState } from 'react';

let goodActiveSubscriptions = 0;

function goodSubscribeToExternalService() {
  goodActiveSubscriptions++;
  console.log(`✅ 陷阱4修复: 订阅外部服务。当前活动订阅: ${goodActiveSubscriptions}`);
  return {
    unsubscribe: () => {
      goodActiveSubscriptions--;
      console.log(`✅ 陷阱4修复: 取消订阅外部服务。当前活动订阅: ${goodActiveSubscriptions}`);
    }
  };
}

function GoodEffectCleanupComponent() {
  const [data, setData] = useState(0);

  useEffect(() => {
    const service = goodSubscribeToExternalService();
    const interval = setInterval(() => {
      setData(prev => prev + 1);
    }, 1000);

    // ✅ 陷阱4修复: 返回清理函数
    return () => {
      console.log("✅ 陷阱4修复: 正在执行 useEffect 清理...");
      service.unsubscribe();
      clearInterval(interval);
    };
  }, []); // 依赖数组为空

  return (
    <div style={{ border: '1px solid green', margin: '10px', padding: '10px' }}>
      <h3>陷阱4修复: `useEffect`正确清理</h3>
      <p>数据: {data}</p>
      <p>请观察控制台的订阅计数。</p>
    </div>
  );
}

严格模式下的输出：

✅ 陷阱4修复: 订阅外部服务。当前活动订阅: 1
✅ 陷阱4修复: 正在执行 useEffect 清理...
✅ 陷阱4修复: 取消订阅外部服务。当前活动订阅: 0
✅ 陷阱4修复: 订阅外部服务。当前活动订阅: 1

现在，你会看到尽管useEffect的设置函数被调用了两次，但第一次订阅后立即被清理了，确保任何时候都只有一个活动订阅。这是正确处理副作用的方式。

5.5 陷阱5：useEffect依赖项不完整或不正确

虽然严格模式的双重渲染主要关注副作用的纯度和清理，但它间接提醒我们useEffect的依赖项列表的重要性。如果依赖项列表不完整，useEffect可能会使用到过期的变量，导致闭包陷阱。虽然双重渲染不直接暴露这个问题，但它强调了useEffect语义的准确性。

示例：不完整的依赖项

import React, { useState, useEffect } from 'react';

function BadEffectDepsComponent() {
  const [count, setCount] = useState(0);
  const [message, setMessage] = useState('');

  // ❌ 陷阱5: 依赖数组为空，但内部使用了外部变量`message`
  // 首次渲染后，这个effect会捕获到`message`的初始值（空字符串）。
  // 即使`message`后来更新，这个effect也不会重新运行。
  useEffect(() => {
    console.log(`❌ 陷阱5: useEffect (消息): 当前消息是 "${message}"`);
    // 假设这里有一个操作是基于message的
  }, []); // 应该依赖 [message]

  return (
    <div style={{ border: '1px solid teal', margin: '10px', padding: '10px' }}>
      <h3>陷阱5: `useEffect`依赖项问题</h3>
      <p>计数: {count}</p>
      <p>消息: {message}</p>
      <button onClick={() => setCount(count + 1)}>增加计数</button>
      <button onClick={() => setMessage(`Hello from ${count}!`)}>设置消息</button>
    </div>
  );
}

严格模式下的暴露：

严格模式会执行两次useEffect，但两次都将使用message的初始值（空字符串）。如果你点击“设置消息”按钮，message会更新，但useEffect不会再次运行，控制台也不会打印新的消息。这表明useEffect没有正确响应message的变化。

解决方案：提供完整的依赖项列表

import React, { useState, useEffect } from 'react';

function GoodEffectDepsComponent() {
  const [count, setCount] = useState(0);
  const [message, setMessage] = useState('');

  // ✅ 陷阱5修复: 依赖数组包含`message`
  useEffect(() => {
    console.log(`✅ 陷阱5修复: useEffect (消息): 当前消息是 "${message}"`);
  }, [message]); // 依赖message

  return (
    <div style={{ border: '1px solid green', margin: '10px', padding: '10px' }}>
      <h3>陷阱5修复: `useEffect`完整依赖项</h3>
      <p>计数: {count}</p>
      <p>消息: {message}</p>
      <button onClick={() => setCount(count + 1)}>增加计数</button>
      <button onClick={() => setMessage(`Hello from ${count}!`)}>设置消息</button>
    </div>
  );
}

现在，当你点击“设置消息”按钮时，useEffect会响应message的变化并打印更新后的消息。

6. 幂等性 (Idempotence)：并发React的黄金法则

在React的并发世界中，幂等性是一个至关重要的概念。一个操作是幂等的，意味着即使你重复执行它多次，其结果也与只执行一次相同。

对于React组件而言，这意味着：

  • 渲染函数必须是幂等的：无论React调用你的组件函数多少次，它都应该始终返回相同的JSX结构，并且不应该对外部世界造成任何不可撤销的副作用。
  • useState的初始化函数必须是幂等的：它应该只计算一个初始值，并且不应有副作用。
  • useMemo和useCallback的回调函数必须是幂等的：它们应该只进行纯计算或返回纯函数。
  • useEffect的设置函数和清理函数必须协同工作以实现幂等性：即使设置函数被多次调用，如果每次都有相应的清理，那么最终状态应该是一致的，就像只执行了一次一样。

严格模式的双重渲染，正是通过强制执行两次操作来检查你的代码是否满足这种幂等性。如果你的代码在严格模式下表现异常（如无限循环、资源泄露、数据不一致），那很可能就违反了幂等性原则。

为什么幂等性如此重要？
因为在并发渲染中，React可能会：

  1. 开始渲染一个组件，但由于优先级更高的更新而暂停。
  2. 稍后恢复渲染，或者完全丢弃之前的渲染工作。
  3. 在后台“预渲染”组件，以准备在未来某个时间点显示。
  4. 在不向用户显示的情况下，多次执行渲染工作，以找到最佳的渲染路径。

如果你的组件渲染函数或其相关逻辑不是幂等的，那么这些内部的、不可见的重复执行就可能导致真实世界的副作用被多次触发，从而产生难以调试的bug。

7. 实践意义与最佳实践

理解双重渲染并非为了避免它，而是为了更好地利用它。以下是一些关键的实践意义和最佳实践：

  1. 拥抱严格模式：

    • 始终在开发环境中使用<React.StrictMode>。它是一个宝贵的诊断工具，能帮助你编写更符合未来React架构的代码。
    • 永远不要在生产环境中禁用它（因为它只在开发环境有效，不会影响生产性能）。

  2. 保持渲染函数纯净：

    • 组件的函数体（或render方法）应该只负责接收props和state，然后返回JSX。
    • 避免在渲染函数中执行任何副作用，如：setState、fetch、setTimeout、setInterval、直接操作DOM、修改外部变量等。

  3. 正确使用useEffect：

    • 将所有副作用（数据获取、订阅、手动DOM操作、定时器等）都放在useEffect中。
    • 对于需要清理的副作用（如订阅、事件监听、定时器），务必返回一个清理函数。这是避免资源泄露的关键。
    • 确保useEffect的依赖项数组完整且准确，避免闭包陷阱。

  4. 惰性初始化useState：

    • 如果useState的初始值需要通过昂贵的计算获得，请传入一个函数：useState(() => expensiveCalculation())。这样可以确保计算只在组件首次渲染时执行一次。

  5. 确保useMemo和useCallback的回调函数纯净：

    • useMemo和useCallback的回调函数只应进行纯计算或返回纯函数。任何副作用都应该移至useEffect。

  6. 开发阶段的性能考量：

    • 严格模式下的双重渲染可能会让你的控制台看起来很“嘈杂”，并且在某些情况下会略微增加开发环境的渲染时间。但请记住，这只是开发工具的开销，不会影响生产环境的性能。它的目的是为了代码的正确性和健壮性，而不是开发时的速度。

  7. 测试与调试：

    • 当你看到严格模式下的警告或不寻常的日志输出时，不要忽视它。这通常是你代码中存在潜在问题的信号，值得你停下来进行检查和修复。

8. 深入理解：React内部的并发机制 (简述)

为了更全面地理解双重渲染的必要性，我们可以简单地触及React内部的并发机制，即Fiber架构和Scheduler。

  • Fiber 架构：React 16引入了Fiber架构，它是一个完全重写的协调器（reconciler）。Fiber将渲染工作分解成一个个小的“工作单元”（Fiber节点），每个Fiber节点代表一个组件或一个DOM元素。这种细粒度的分解使得React可以在渲染过程中暂停和恢复。
  • Scheduler (调度器)：React的调度器负责决定何时执行哪个工作单元。它能够根据任务的优先级（例如，用户输入事件的优先级高于数据加载）来调度工作。当有更高优先级的任务出现时，调度器可以指示Fiber暂停当前正在进行的低优先级渲染工作，并将控制权交还给浏览器，或者转去处理高优先级任务。

正是这种可中断、可暂停、可丢弃的渲染能力，使得React能够实现更流畅的用户体验。但这也意味着，任何在渲染阶段执行的副作用都可能在不完整或被丢弃的工作中发生，从而导致问题。严格模式下的双重渲染，正是为了帮助开发者在开发阶段，提前发现并解决这些与并发特性不兼容的代码模式。

9. 结语

严格模式下的“双重渲染”并非Bug，而是React团队为我们精心准备的一份礼物——一个强大的诊断工具。它通过在开发环境中模拟并发渲染的复杂场景，帮助我们提前发现并修复代码中潜在的副作用和不纯之处。

掌握纯函数、正确管理副作用、以及理解幂等性的重要性，是编写健壮、可维护、并能充分利用React未来并发特性的关键。拥抱严格模式，让它成为你日常开发中的得力助手，你将能够构建出更稳定、更具响应性的React应用。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注