解析 React 的 ‘Effect Cleanup’ 机制：在并发模式下，旧的清理函数可能在新的 Effect 之后执行吗？

在 React 的世界中，副作用（Effects）是连接组件内部逻辑与外部系统（如 DOM、网络请求、订阅、定时器等）的桥梁。useEffect Hook 提供了一种声明式的方式来处理这些副作用，并强制我们思考如何清理它们。随着 React 引入并发模式（Concurrent Mode），副作用的清理机制变得更加微妙和复杂，尤其是在“旧的清理函数是否可能在新的 Effect 之后执行”这一问题上，引发了开发者社区的广泛讨论和深入探究。

本讲座将深入解析 React 的 Effect Cleanup 机制，尤其是在并发模式下的行为。我们将从基础概念出发，逐步深入到并发模式带来的挑战，并探讨 React 内部如何解决这些问题，以确保应用程序的正确性和稳定性。

---

第一章：React Effect 的基础与清理的必要性

React 组件的生命周期中，除了渲染 UI 之外，经常需要执行一些与 UI 渲染本身无关的操作，这些操作被称为副作用。例如：

• 数据获取 (Data Fetching)：从 API 获取数据。
• 订阅 (Subscriptions)：监听外部数据源（如 WebSocket、Redux store、事件总线）。
• 手动改变 DOM (Manually changing the DOM)：直接操作 DOM 元素，例如设置焦点、播放媒体。
• 定时器 (Timers)：setTimeout, setInterval。
• 日志记录 (Logging)：在特定生命周期阶段发送分析事件。

useEffect Hook 允许我们在函数组件中声明这些副作用。它的基本结构如下：

useEffect(() => {
  // 副作用的设置代码 (Setup)
  console.log('Effect setup running');

  // 返回一个清理函数 (Cleanup)
  return () => {
    console.log('Effect cleanup running');
    // 清理代码
  };
}, [dependencies]); // 依赖数组

清理的必要性

为什么需要清理函数？想象一个组件订阅了一个外部服务。如果组件在没有取消订阅的情况下被卸载，或者重新渲染时没有清理旧的订阅就创建了新的订阅，就会导致：

1. 内存泄漏 (Memory Leaks)：旧的订阅会继续占用内存和资源，即使组件已经不再需要它。
2. 不一致的数据 (Stale Data)：组件可能仍在接收来自旧订阅的数据，导致 UI 显示不正确。
3. 重复操作 (Duplicate Operations)：多次订阅同一个服务，导致不必要的网络请求或事件处理。
4. 竞态条件 (Race Conditions)：在快速更新的场景下，旧的副作用操作可能与新的副作用操作发生冲突。

清理函数的作用就是释放由副作用创建的资源，撤销副作用的影响。它确保了副作用是“原子性”的，即在组件的生命周期中，每个副作用都有其对应的设置和清理过程，避免了资源浪费和逻辑错误。

同步模式下的 Effect 生命周期

在 React 的同步渲染模式下，Effect 的清理和设置顺序是相对直观的：

1. 首次渲染 (Mount)：
   • 组件渲染并提交到 DOM。
   • useEffect 的设置函数执行。
2. 更新 (Update)：
   • 组件因 state 或 props 变化而重新渲染。
   • React 会在执行新的 useEffect 设置函数之前，先执行上一次 useEffect 返回的清理函数。
   • 新的 useEffect 设置函数执行。
3. 卸载 (Unmount)：
   • 组件被从 DOM 中移除。
   • 最后一次 useEffect 返回的清理函数执行。

我们可以用一个简单的计数器组件来演示这个流程：

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

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

  useEffect(() => {
    console.log(`Effect setup for count: ${count}`);
    const timerId = setInterval(() => {
      // 模拟一个副作用，比如每秒更新一个外部状态或日志
      console.log(`Interval active, current count: ${count}`);
    }, 1000);

    return () => {
      console.log(`Effect cleanup for count: ${count}`);
      clearInterval(timerId); // 清理定时器
    };
  }, [count]); // 依赖 count

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(prevCount => prevCount + 1)}>
        Increment
      </button>
    </div>
  );
}

function App() {
  const [showCounter, setShowCounter] = useState(true);

  return (
    <div>
      <button onClick={() => setShowCounter(!showCounter)}>
        Toggle Counter
      </button>
      {showCounter && <Counter />}
    </div>
  );
}

export default App;

观察上述代码的控制台输出：

1. 组件挂载 Counter：

   Effect setup for count: 0
   Interval active, current count: 0
   Interval active, current count: 0
   ...

2. 点击 Increment 按钮，count 从 0 变为 1：

   Effect cleanup for count: 0  // 旧的 effect 清理
   Effect setup for count: 1    // 新的 effect 设置
   Interval active, current count: 1
   Interval active, current count: 1
   ...

3. 点击 Toggle Counter 按钮，卸载 Counter 组件：

   Effect cleanup for count: 1 // 最后一次的 effect 清理

从这个例子中，我们可以清晰地看到，在同步模式下，useEffect 的清理总是发生在下一次设置之前，或者在组件卸载之前。这种严格的顺序保证了副作用管理的确定性。

---

第二章：React 并发模式的引入与挑战

React 18 引入了并发渲染（Concurrent Rendering）的概念，这是 React 架构上的一次重大飞跃。并发模式旨在通过可中断的渲染工作来提升用户体验，使得应用程序能够更好地响应用户输入，即使在处理大量或计算密集型任务时也能保持 UI 的流畅。

并发模式的核心思想：

• 可中断性 (Interruptibility)：渲染工作不再是不可中断的。React 可以暂停当前正在进行的渲染，处理更高优先级的更新（例如用户输入），然后再恢复或放弃之前的渲染。
• 时间切片 (Time Slicing)：React 将渲染工作分割成小块，在浏览器空闲时执行这些小块工作，避免长时间阻塞主线程。
• 优先级 (Prioritization)：不同的更新可以有不同的优先级。例如，用户输入（如文本输入）的优先级高于不重要的后台数据加载。
• 多版本 UI (Multiple UI Versions)：React 可以在内存中同时准备多个 UI 版本，但只会提交（Commit）其中一个版本到实际 DOM。

并发模式对 Effect 清理带来的挑战

在同步模式下，渲染总是同步且不可中断的。一旦渲染开始，它就会一直进行直到完成，然后才提交到 DOM，并触发副作用。但在并发模式下，这个模型被打破了：

1. 渲染可能被中断或放弃 (Interrupted or Aborted Renders)：一个正在进行的渲染可能会因为更高优先级的更新而暂停。如果更高优先级的更新导致一个完全不同的 UI 状态，那么之前被暂停的渲染结果可能就完全失效并被放弃。
2. 提交的时机不确定 (Uncertain Commit Timings)：虽然 React 最终会提交一个渲染结果，但从渲染开始到提交之间的时间窗口可能很长，且期间可能发生多次中断。
3. Effect 与视觉更新的解耦 (Decoupling Effects from Visual Updates)：为了保持 UI 的响应性，React 在并发模式下将 useEffect（称为“被动效果”或 “Passive Effects”）的执行时机推迟到浏览器绘制完成之后。这意味着用户可能已经看到了更新后的 UI，但相关的副作用（包括清理和设置）可能尚未执行。

正是由于这些特性，引发了我们核心的疑问：“在并发模式下，旧的清理函数可能在新的 Effect 之后执行吗？”

---

第三章：并发模式下 Effect 清理的精确机制

要回答“旧的清理函数可能在新的 Effect 之后执行吗？”这个问题，我们需要区分两种 Effect：

1. useLayoutEffect (布局效果)：这些效果在 DOM 更新后、浏览器绘制前同步执行。它们的清理也遵循同步模式的严格顺序。
2. useEffect (被动效果)：这些效果在浏览器绘制完成后异步执行。它们的清理和设置是批量进行的，并由 React 的调度器在空闲时间执行。

核心结论：对于同一个组件实例的同一个 useEffect，React 保证旧的清理函数总是先于新的设置函数执行。

这个保证是 React 副作用管理的基础。如果这个保证被打破，那么副作用系统就不可靠了。然而，并发模式确实引入了关于“何时”执行这些操作的微妙之处，这可能会让开发者产生“旧清理在后”的错觉。

让我们深入探讨 useEffect 在并发模式下的具体行为：

1. useEffect 的调度与批处理

在并发模式下，useEffect 的清理和设置不再是紧密耦合到单个渲染周期的同步操作。相反，它们被视为“被动”操作，会在浏览器绘制完成后，由 React 调度器在非阻塞的方式下执行。

• 当一个组件更新并提交到 DOM 后，React 会收集所有需要清理的旧 useEffect 函数和所有需要设置的新 useEffect 函数。
• 这些函数会被放入一个队列中，并等待 React 的调度器在浏览器空闲时批量执行。

2. 批处理的顺序保证

即使是批处理，React 也会严格维护每个 Effect 的清理-设置顺序。具体来说：

• 对于一个组件的 useEffect 实例，如果它的依赖项发生变化，React 会确保在执行新的设置函数之前，先执行上一个渲染周期的清理函数。
• 这个保证适用于同一个组件的同一个 Effect 实例。

3. “旧清理在后”的误解来源

那么，“旧的清理函数可能在新的 Effect 之后执行吗？”这个疑问究竟是怎么产生的呢？它通常源于对“何时”执行和“什么”执行的混淆。

考虑以下场景：

1. 组件 A 首次渲染并提交。其 useEffect 设置函数运行，创建了一个资源 R1。
2. 组件 A 很快地接收到一个更新，触发第二次渲染。
3. 在并发模式下，React 开始渲染新的 UI。这个渲染可能被中断，但最终它会成功提交。
4. 当新的 UI 提交后，浏览器会进行绘制。
5. 在浏览器绘制完成后，React 调度器会处理 useEffect。它会首先执行第一次渲染的清理函数（释放 R1），然后执行第二次渲染的设置函数（创建新的资源 R2）。

在这个过程中，从用户看到 UI 更新到清理和设置函数实际执行之间可能存在一个微小的时间窗口。如果在这个窗口内，我们没有意识到 Effect 尚未执行，可能会产生错觉。

关键点在于： 即使渲染和提交是并行的，或者 Effect 的执行被延迟了，React 仍然会确保：对于某个特定的 useEffect 调用，其上一次的清理总是发生在其新一次的设置之前。

我们来看一个更具体的例子，假设我们有一个组件 MyComponent，它有一个 useEffect。

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

function MyComponent({ value }) {
  const [internalState, setInternalState] = useState(0);

  useEffect(() => {
    console.log(`[Effect ${value}] Setting up resource for value: ${value}, internalState: ${internalState}`);
    const resource = `Resource-${value}-${internalState}`; // 模拟创建资源

    // 模拟异步操作
    const timerId = setTimeout(() => {
      console.log(`[Effect ${value}] Resource '${resource}' fully active.`);
    }, 100);

    return () => {
      clearTimeout(timerId);
      console.log(`[Effect ${value}] Cleaning up resource for value: ${value}, internalState: ${internalState}`);
      // 模拟释放资源
    };
  }, [value, internalState]); // 依赖 value 和 internalState

  // 模拟一个内部状态的变化，这也会触发 Effect
  const handleInternalStateChange = () => {
    setInternalState(prev => prev + 1);
  };

  return (
    <div>
      <p>Value: {value}</p>
      <p>Internal State: {internalState}</p>
      <button onClick={handleInternalStateChange}>Change Internal State</button>
    </div>
  );
}

function App() {
  const [inputValue, setInputValue] = useState(0);
  const [showComponent, setShowComponent] = useState(true);

  return (
    <div>
      <input
        type="number"
        value={inputValue}
        onChange={(e) => setInputValue(Number(e.target.value))}
      />
      <button onClick={() => setShowComponent(!showComponent)}>
        Toggle MyComponent
      </button>
      {showComponent && <MyComponent value={inputValue} />}
    </div>
  );
}

export default App;

在并发模式下（例如通过 createRoot 使用），如果我们快速地修改 inputValue：

1. 初始渲染 inputValue = 0, internalState = 0：

   [Effect 0] Setting up resource for value: 0, internalState: 0
   // (100ms later) [Effect 0] Resource 'Resource-0-0' fully active.

2. 快速输入 1 (inputValue 变为 1)：
   React 可能会在后台开始渲染 MyComponent 与 value=1。这个渲染可能在完成前就被用户输入 2 打断。
   假设 value=1 的渲染成功提交：

   [Effect 0] Cleaning up resource for value: 0, internalState: 0 // 旧 Effect 清理
   [Effect 1] Setting up resource for value: 1, internalState: 0   // 新 Effect 设置
   // (100ms later) [Effect 1] Resource 'Resource-1-0' fully active.

3. 再次快速输入 2 (inputValue 变为 2)：
   同样，React 提交新渲染：

   [Effect 1] Cleaning up resource for value: 1, internalState: 0 // 旧 Effect 清理
   [Effect 2] Setting up resource for value: 2, internalState: 0   // 新 Effect 设置
   // (100ms later) [Effect 2] Resource 'Resource-2-0' fully active.

观察点：

• 即使我快速输入，你仍然会看到清理总是发生在下一个设置之前。
• console.log 的输出时间可能会因为批处理和异步执行而略有延迟，但逻辑顺序是严格遵循的。

并发模式下真正可能发生的“错位”感：

并发模式下，一个组件可能会进行多次渲染，但只有最后一次成功的渲染会被提交。如果在渲染过程中，Effect setup/cleanup 相关的调度任务被放入队列，而随后的高优先级更新导致该渲染被丢弃，那么该渲染相关的 Effect 任务也会被取消。

然而，对于已经提交的渲染，其 Effect 的清理和设置顺序是严格保证的。你可能会看到在 UI 已经更新后的一小段时间内，旧的清理函数和新的设置函数才陆续在控制台输出，这是因为 useEffect 是“被动”执行的，它不阻碍浏览器绘制。这种视觉上的“提前”和 Effect 逻辑上的“延迟”可能会让人产生误解。

总结表格：Effect 清理/设置时机

特性 / Effect 类型	useEffect (Passive Effect)	useLayoutEffect (Layout Effect)
执行时机 (同步模式)	在 DOM 更新和浏览器绘制后（异步）	在 DOM 更新后、浏览器绘制前（同步）
执行时机 (并发模式)	在 DOM 更新和浏览器绘制后（异步，可能延迟执行，批处理）	在 DOM 更新后、浏览器绘制前（同步，阻碍绘制）
清理时机 (更新)	在下一次 Effect 设置之前，但可能与 DOM 更新有时间差	在下一次 Effect 设置之前，紧随 DOM 更新
清理时机 (卸载)	组件卸载时执行最后一次清理	组件卸载时执行最后一次清理
是否阻塞渲染	否	是 (会阻塞浏览器绘制)
用途	大多数副作用，不涉及 DOM 测量或布局同步	需要同步 DOM 测量、修改 DOM 布局或与布局强相关的副作用
并发模式下“旧清理在后”	不会发生。React 保证清理-设置顺序，但执行可能延迟。	不会发生。始终同步执行。

严谨的回答：旧的清理函数可能在新的 Effect 之后执行吗？

答案是：否。在 React 的任何模式下，对于同一个组件实例的同一个 useEffect 或 useLayoutEffect，其上一次渲染的清理函数，总是在下一次渲染的设置函数之前执行。

并发模式引入的“延迟”只是针对 useEffect 的执行时机，而不是执行顺序。React 内部的调度器会确保即使这些操作被批处理或延迟，它们之间的逻辑顺序（清理在设置之前）仍然得到严格遵守。

这个保证是 React 副作用模型的核心，没有它，我们无法可靠地管理资源和避免竞态条件。

---

第四章：Strict Mode (严格模式) 与 Effect 双重调用

React 的严格模式 (<React.StrictMode>) 是一个开发工具，用于帮助开发者发现潜在的副作用问题。在严格模式下，为了更好地暴露问题，React 会：

• 在开发环境下，组件首次挂载时，useEffect 的设置函数会被调用两次，并且第一次调用后会立即执行清理函数。

这个行为可以概括为：

1. 组件挂载。
2. useEffect 设置函数执行 (第一次)。
3. useEffect 清理函数执行 (第一次清理)。
4. useEffect 设置函数执行 (第二次)。

这种双重调用是模拟一个快速的挂载-卸载-再挂载或者快速的更新周期。它旨在帮助开发者：

• 检查 Effect 的清理是否完整和正确：如果你的 Effect 没有提供清理函数，或者清理函数不完善，那么双重调用会导致资源泄漏或意想不到的行为，从而暴露问题。例如，一个没有清理的订阅会在短时间内创建两个订阅。
• 确保 Effect 的幂等性：一个正确的 Effect 应该能够处理多次设置和清理，而不产生副作用。

示例：严格模式下的 Effect

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

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

  useEffect(() => {
    console.log(`[Strict Mode Effect] Setup for count: ${count}`);
    const interval = setInterval(() => {
      console.log(`[Strict Mode Interval] Count: ${count}`);
    }, 1000);

    return () => {
      console.log(`[Strict Mode Effect] Cleanup for count: ${count}`);
      clearInterval(interval);
    };
  }, [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(prev => prev + 1)}>Increment</button>
    </div>
  );
}

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

export default App;

控制台输出 (首次挂载)：

[Strict Mode Effect] Setup for count: 0
[Strict Mode Effect] Cleanup for count: 0
[Strict Mode Effect] Setup for count: 0
[Strict Mode Interval] Count: 0
[Strict Mode Interval] Count: 0
...

重要提示：

• 严格模式下的双重调用仅发生在开发环境。在生产构建中，Effect 只会执行一次。
• 这个行为不应被误解为并发模式下的实际生产行为。它是一个调试工具，用于帮助开发者编写更健壮的 Effect。

理解严格模式有助于我们更好地编写具备良好清理机制的 Effect，因为如果你的清理做得不够好，严格模式会立即暴露问题。

---

第五章：代码示例与最佳实践

为了进一步巩固理解，并展示如何在实际开发中应用这些知识，我们将提供更多代码示例，并总结 Effect 清理的最佳实践。

示例 1：管理外部订阅

假设我们有一个外部的事件发布/订阅系统。

// external-event-bus.js
const eventHandlers = {};

export const EventBus = {
  subscribe(event, handler) {
    if (!eventHandlers[event]) {
      eventHandlers[event] = [];
    }
    eventHandlers[event].push(handler);
    console.log(`Subscribed to ${event}. Total handlers: ${eventHandlers[event].length}`);
    return () => { // 返回一个取消订阅的函数
      eventHandlers[event] = eventHandlers[event].filter(h => h !== handler);
      console.log(`Unsubscribed from ${event}. Total handlers: ${eventHandlers[event].length}`);
    };
  },
  publish(event, data) {
    if (eventHandlers[event]) {
      eventHandlers[event].forEach(handler => handler(data));
    }
  },
};

// Component.js
import React, { useState, useEffect } from 'react';
import { EventBus } from './external-event-bus';

function DataDisplay({ eventType }) {
  const [data, setData] = useState('No data yet');

  useEffect(() => {
    console.log(`[${eventType}] Effect setup: Subscribing to ${eventType}`);
    const unsubscribe = EventBus.subscribe(eventType, (newData) => {
      setData(newData);
      console.log(`[${eventType}] Received data: ${newData}`);
    });

    return () => {
      console.log(`[${eventType}] Effect cleanup: Unsubscribing from ${eventType}`);
      unsubscribe(); // 调用清理函数
    };
  }, [eventType]); // 依赖 eventType

  return (
    <div style={{ border: '1px solid gray', padding: '10px', margin: '10px' }}>
      <h3>Display for '{eventType}'</h3>
      <p>Current Data: {data}</p>
    </div>
  );
}

function App() {
  const [currentEvent, setCurrentEvent] = useState('userClicked');

  useEffect(() => {
    // 模拟发布事件
    const interval = setInterval(() => {
      EventBus.publish(currentEvent, `Data from ${currentEvent} at ${new Date().toLocaleTimeString()}`);
    }, 2000);
    return () => clearInterval(interval);
  }, [currentEvent]);

  return (
    <div>
      <select value={currentEvent} onChange={(e) => setCurrentEvent(e.target.value)}>
        <option value="userClicked">User Clicked</option>
        <option value="dataUpdated">Data Updated</option>
        <option value="statusChanged">Status Changed</option>
      </select>
      <DataDisplay eventType={currentEvent} />
    </div>
  );
}

export default App;

观察点： 快速切换 select 选项时，你会看到旧 eventType 的订阅会先被取消，然后新 eventType 的订阅才会被创建。这是 React 严格遵循清理-设置顺序的体现，即使在并发模式下也是如此。

示例 2：useLayoutEffect 的应用

当需要同步测量或修改 DOM 布局时，useLayoutEffect 是正确的选择。

import React, { useState, useRef, useLayoutEffect } from 'react';

function Tooltip({ children, text }) {
  const [tooltipStyle, setTooltipStyle] = useState({});
  const ref = useRef(null);

  useLayoutEffect(() => {
    if (!ref.current) return;

    // 假设我们需要将 Tooltip 放置在 children 元素的右侧
    const rect = ref.current.getBoundingClientRect();
    console.log(`[Layout Effect] Measuring DOM for text: ${text}`);

    setTooltipStyle({
      position: 'absolute',
      top: rect.top + window.scrollY + 'px',
      left: rect.right + 10 + window.scrollX + 'px',
      backgroundColor: 'black',
      color: 'white',
      padding: '5px',
      borderRadius: '3px',
      zIndex: 1000,
    });

    return () => {
      console.log(`[Layout Effect] Cleanup for text: ${text}`);
      // 清理任何手动添加的 DOM 元素或事件监听器
    };
  }, [children, text]); // 依赖 children 和 text 可能会导致重新计算

  return (
    <>
      <span ref={ref} style={{ display: 'inline-block', position: 'relative' }}>
        {children}
      </span>
      {tooltipStyle.top && (
        <div style={tooltipStyle}>
          {text}
        </div>
      )}
    </>
  );
}

function App() {
  const [message, setMessage] = useState('Hello React');

  return (
    <div style={{ padding: '50px' }}>
      <input
        type="text"
        value={message}
        onChange={(e) => setMessage(e.target.value)}
        style={{ marginBottom: '20px' }}
      />
      <Tooltip text={`Current message: ${message}`}>
        <button>Hover me</button>
      </Tooltip>
      <p style={{ marginTop: '100px' }}>Scroll down to see more content...</p>
      {/* 模拟更多内容，让页面可滚动 */}
      {[...Array(20)].map((_, i) => <p key={i}>Some placeholder content {i}</p>)}
    </div>
  );
}

export default App;

观察点：

• useLayoutEffect 会在每次 message 变化并导致 DOM 更新后立即执行，确保 Tooltip 的位置在浏览器绘制前就已经计算好，避免了闪烁。
• 它的清理和设置是同步的，不会被延迟。

---

Effect 清理的最佳实践

1. 始终提供清理函数（如果需要）：如果你的 Effect 执行了任何需要撤销的操作（如订阅、定时器、手动 DOM 操作、打开的资源句柄），那么务必返回一个清理函数。
2. 清理函数应该具有幂等性：清理函数应该能够安全地多次运行，或者在资源可能已经不存在的情况下也能正常工作。例如，clearInterval 或 clearTimeout 在多次调用时不会引起错误。
3. 正确设置依赖数组：
   • 空数组 []：Effect 只在组件挂载时运行一次设置，在卸载时运行一次清理。适用于只在组件生命周期中一次性设置和清理的副作用。
   • 无依赖数组：Effect 在每次渲染后都会运行设置和清理。这很少是期望的行为，通常会导致性能问题。
   • 包含依赖项：Effect 仅在依赖项发生变化时重新运行设置和清理。这是最常见的用法。确保所有 Effect 内部使用的、可能随时间变化的变量（props, state, functions）都包含在依赖数组中。
4. 区分 useEffect 和 useLayoutEffect：
   • useEffect：适用于大多数副作用，特别是那些不需要立即反映在 DOM 上的操作，或那些可能耗时的操作。它不会阻塞 UI 绘制，从而保证了用户体验的流畅性。
   • useLayoutEffect：仅当你的副作用需要同步读取 DOM 布局信息（如 getBoundingClientRect）或同步修改 DOM 布局时使用。因为它会阻塞浏览器绘制，所以滥用会导致性能问题。
5. 避免在 Effect 中直接修改依赖项：这可能导致无限循环。如果必须修改，请确保修改操作被限制在 Effect 的清理阶段，或者通过 useRef 等方式脱离 Effect 的依赖追踪。
6. 使用自定义 Hook 封装复杂逻辑：将相关的副作用逻辑封装到自定义 Hook 中，可以提高代码的可重用性和可维护性，并帮助管理复杂的清理逻辑。

---

第六章：思考与展望

通过对 React Effect 清理机制的深入探讨，我们可以得出以下核心认知：

React 设计 useEffect 的清理机制时，始终秉持着一个核心原则：保证副作用的生命周期完整性，即一个副作用实例的清理操作总是在其新实例的设置操作之前发生。 这一点，无论是在同步模式还是并发模式下，都得到了严格的遵守。

并发模式确实引入了 useEffect 执行时机的“异步性”和“延迟性”，这使得 Effect 的清理和设置不再像在同步模式下那样与 UI 绘制紧密同步。但这种延迟是为了优化用户体验，避免阻塞主线程，而不是为了打破 Effect 内部的逻辑顺序。开发者可能会因为 UI 已经更新而 Effect 仍在后台排队执行，从而产生“旧清理在后”的错觉，但从 React 内部的调度逻辑来看，其顺序是严格保证的。

理解这一机制对于编写健壮、高效的 React 应用至关重要。它促使我们更加严谨地思考副作用的生命周期，正确地编写清理函数，并合理地选择 useEffect 或 useLayoutEffect。随着 React 生态的不断演进，并发模式将变得越来越普遍，深入理解其背后的原理，将帮助我们更好地驾驭 React 的强大能力。