React 逻辑推演：并发更新中断后的状态清理

（敲黑板，清嗓子）

好，同学们，把手里的咖啡放下，把手机静音。今天我们不聊那些花里胡哨的 Hooks，也不聊组件怎么拆分。咱们今天要聊点“硬核”的，聊点让无数 React 开发者在深夜里对着屏幕抓狂的东西——并发模式下的状态清理与中断逻辑。

这听起来是不是有点像某种高深的量子力学？别怕，咱们把它拆解了，就像拆解一个虽然复杂但本质还是由螺丝和螺母组成的机械闹钟一样。

准备好了吗？我们要开始“进阶”了。

第一部分：当 React 开始“分心”

首先，咱们得搞清楚什么是“并发更新”。在 React 18 之前，React 是个非常听话的“老实孩子”。你喊一声“渲染”，它就埋头苦干，把整个组件树画完，把 DOM 更新完，才停下来喘口气。在这个过程中，你哪怕点击了一百次按钮，它也只认第一下，剩下的九十九下它都当没看见，或者干脆等到第一下渲染完了再处理。

但是，React 18 觉得这样太“阻塞”了。用户体验上，如果一个大型的列表正在加载，你还在那里疯狂点击“刷新”，界面卡得像在放幻灯片，这体验太差了。

于是，React 变“聪明”了，它学会了“并发”。它现在会根据事情的“紧急程度”来安排工作。比如，你正在打字（高优先级），它就先处理打字；如果你点击了一个“加载更多数据”的按钮（低优先级），它可能会停下来，看看键盘有没有反应，或者先处理一下屏幕上飘来的通知（高优先级）。

这就引出了我们今天的主角：中断。

当一个低优先级的任务正在执行（比如渲染一个复杂的图表），突然来了一个高优先级的任务（比如用户点击了“提交表单”），React 会怎么做？它会中断那个低优先级任务。

那么问题来了：那个被中断的低优先级任务，它正在做的事情（比如正在设置一个状态），是不是就白费了？那个状态还会不会出现在界面上？如果那个任务里还开了个定时器，或者发了个网络请求，这些垃圾会不会留在内存里？

这就是我们要推演的逻辑：并发更新中断后的状态清理。

第二部分：setState 的“消失术”

咱们先看最简单的 setState。

假设你有一个按钮，点击它会触发一个异步操作，并且更新状态。

import React, { useState } from 'react';

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

  const handleClick = () => {
    console.log('开始处理，优先级低');
    setCount(prev => prev + 1); // 这是一个低优先级更新，因为它在 setTimeout 里

    setTimeout(() => {
      console.log('异步回调执行');
      setCount(prev => prev + 1);
    }, 2000);
  };

  return (
    <div>
      <h1>当前计数: {count}</h1>
      <button onClick={handleClick}>点击我</button>
    </div>
  );
}

同学们，请闭上眼睛想象一下这个场景。你点击了按钮。

1. React 开始执行 handleClick。
2. 它先执行了 setCount(prev => prev + 1)。这时候，它把这个更新加入到了“更新队列”里。注意，这时候它还没真正去修改 DOM，它只是在脑子里记了一笔。
3. 然后，它遇到了 setTimeout，觉得“哎，这事儿不急，我先挂起，等会儿再说”。
4. 就在这时候，你的手指太快了，又点击了一次按钮（高优先级）。

这时候，React 会怎么做？它会丢弃第一次的更新，因为第二次更新覆盖了它。第二次更新会重新执行 handleClick，重新设置状态。

推演结果：
2秒后，setTimeout 回调执行了。它尝试再次 setCount。
React 会检查：哦，现在的状态是 count = 1（因为第二次点击覆盖了第一次）。
回调里写的是 prev + 1，所以它变成 2。

注意： setTimeout 里的那个 setCount 依然会执行，它并没有被自动取消！这是很多新手最容易踩的坑。

但是！如果你把逻辑反过来呢？

const handleClick = () => {
  console.log('开始处理');
  // 这里的 setCount 变成了高优先级
  setCount(prev => prev + 1);

  // 假设这里有个非常耗时的计算，把主线程占满了
  const start = performance.now();
  while (performance.now() - start < 10000) {
    // 模拟阻塞
  }

  // 这里的 setCount 变成了低优先级
  setTimeout(() => {
    setCount(prev => prev + 100);
  }, 0);
};

这时候，你点击按钮。

1. setCount(prev + 1) 立即执行，UI 变成 1。
2. React 进入了那个 while 循环（模拟高优先级任务打断）。
3. 10秒后循环结束。
4. setTimeout 里的 setCount(prev + 100) 才有机会执行。

推演结果： 界面上最终显示的是 101。那个低优先级的更新没有被丢弃，它只是被推迟了。

结论：
setState 本身并不直接提供“取消”机制。它依赖于 React 的调度器。如果低优先级更新被高优先级更新覆盖，它就被丢弃了；如果没有被覆盖，它就会排队等待执行。

第三部分：useEffect 的“清洁工”职责

这是最精彩的部分。useEffect 就像是组件的“清洁工”和“管家”。当更新被中断时，React 会请这些管家来打扫卫生。

让我们看一个经典的场景：定时器 + 中断。

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

function TimerComponent() {
  const [isRunning, setIsRunning] = useState(false);

  useEffect(() => {
    console.log('Effect 启动：设置定时器');
    let timerId = setInterval(() => {
      console.log('Tick');
    }, 1000);

    // 返回清理函数
    return () => {
      console.log('Effect 清理：清除定时器');
      clearInterval(timerId);
    };
  }, [isRunning]); // 依赖项是 isRunning

  return (
    <div>
      <p>状态: {isRunning ? '运行中' : '已停止'}</p>
      <button onClick={() => setIsRunning(!isRunning)}>
        {isRunning ? '停止' : '启动'}
      </button>
    </div>
  );
}

场景演练：

1. 初始状态 isRunning = false。Effect 没有运行。
2. 你点击“启动”。isRunning 变为 true。
3. React 开始渲染。它发现了 isRunning 的变化，决定运行 Effect。
4. 定时器启动，每秒打印一次 Tick。
5. 关键时刻来了！ 就在定时器刚启动的一瞬间（第一秒还没到），你疯狂点击“停止”按钮。

推演过程：

1. React 收到了新的更新：isRunning 变为 false。
2. 这是一个高优先级更新（用户交互）。
3. React 停止了当前的渲染流程（中断了旧的 Effect）。
4. React 开始执行清理函数。
   • 它找到了刚才那个定时器，执行 clearInterval(timerId)。
   • 控制台打印：Effect 清理：清除定时器。
5. 然后，React 开始新的渲染，执行新的 Effect。
   • 因为 isRunning 是 false，Effect 不会再次启动定时器。
6. 最终，界面显示“已停止”。

结论：
当更新被中断时，React 一定会运行所有受影响的 useEffect 的清理函数。这是保证状态一致性的一把利剑。

第四部分：并发更新中的“副作用”陷阱

但是，同学们，事情没那么简单。useEffect 的清理函数只是处理副作用（比如取消请求、清除定时器）。那么，如果我们在 useEffect 里直接修改状态呢？这在并发模式下可是个雷区。

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

function DangerousEffect() {
  const [data, setData] = useState(null);

  useEffect(() => {
    console.log('Effect 执行');

    // 模拟一个耗时的异步操作
    const fetchData = async () => {
      await new Promise(resolve => setTimeout(resolve, 3000));

      // 注意！我们在 Effect 里直接 setState 了
      setData('获取到的数据');
    };

    fetchData();

    return () => {
      console.log('Effect 清理');
    };
  }, []);

  return (
    <div>
      <p>数据: {data || '加载中...'}</p>
    </div>
  );
}

场景演练：

1. 组件挂载。
2. useEffect 运行，开始 fetchData，3秒后返回数据。
3. 在这3秒内，你点击了浏览器刷新，或者组件卸载了。
4. 推演：
   • 组件卸载触发 useEffect 的清理函数。
   • 清理函数执行。
   • 但是！清理函数不能阻止 fetchData 里的代码继续执行。
   • 3秒后，fetchData 回调执行，它调用了 setData('获取到的数据')。
   • 此时组件可能已经卸载了（或者处于不可见状态）。
   • React 收到了这个状态更新。但是！ React 会检查当前组件是否还在挂载。如果不在，它会忽略这个更新。这叫“强制更新检查”。
   • 所以，虽然 setData 被调用了，但它不会导致“警告：Can’t perform a React state update on an unmounted component”的报错（如果代码写得好），也不会导致界面闪烁。

但是！如果中断发生在 Effect 执行的过程中呢？

function ConcurrentEffect() {
  const [step, setStep] = useState(1);

  useEffect(() => {
    console.log(`Step ${step}: 开始执行`);

    // 模拟一个长时间的操作，并且在过程中修改状态
    const interval = setInterval(() => {
      console.log(`Step ${step}: 正在运行...`);
      // 这里故意不更新 step，为了模拟中断发生时的状态保留
    }, 1000);

    // 假设 1.5 秒后，有一个高优先级更新中断了这里
    setTimeout(() => {
      // 这里我们模拟 React 中断了这个 Effect 的执行
      // 实际上 React 不会完全“跳过”这个 Effect，而是会重新执行整个 Effect
      // 因为 useEffect 依赖项变了（虽然这里没写依赖项，但内部逻辑变了）

      // 为了演示，我们假设 React 决定重置这个 Effect
      clearInterval(interval);
      console.log('Effect 被中断，清理并重启');

      // 模拟重新进入 Effect
      // 注意：React 可能会直接丢弃这次 Effect 的执行，或者重新执行
      // 如果重新执行，它会再次设置 interval
    }, 1500);

    return () => {
      console.log('清理 Interval');
      clearInterval(interval);
    };
  }, []); // 空依赖

  return <div>Step: {step}</div>;
}

推演：

1. setInterval 开始运行，打印 Step 1: 正在运行...。
2. 1.5秒后，高优先级任务到来。
3. React 中断了当前的 Effect 执行流程。
4. React 运行清理函数：clearInterval(interval)。
5. React 重新开始执行 Effect（因为 Effect 的逻辑在组件函数体内，组件函数会重新执行）。
6. setInterval 再次启动。
7. 3秒后（总共4.5秒），setTimeout 触发，再次清理并重启。

结论：
在并发模式下，如果你在 useEffect 里开启了定时器或者订阅了事件，你必须在清理函数里取消它们。否则，当组件被中断、卸载或重新挂载时，你会得到无数个定时器在后台疯狂运行，内存泄漏就此诞生。

第五部分：startTransition —— 并发的“绅士”

既然直接写 setTimeout 搞低优先级更新这么容易出事，React 官方给我们提供了一个更优雅的工具：startTransition。

它的核心思想是：把状态更新标记为“非紧急”的。

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

function SearchComponent() {
  const [input, setInput] = useState('');
  const [query, setQuery] = useState(''); // 这是我们最终要显示的搜索词
  const [results, setResults] = useState([]);

  const handleChange = (e) => {
    const value = e.target.value;
    setInput(value); // 立即更新输入框（高优先级，同步）

    // 开始一个 Transition
    startTransition(() => {
      setQuery(value); // 延迟更新搜索词（低优先级）
      // 模拟搜索请求
      fetchResults(value).then(res => {
        setResults(res); // 这也是低优先级
      });
    });
  };

  return (
    <div>
      <input value={input} onChange={handleChange} />
      <p>正在搜索: {query}</p>
      <ul>{results.map(r => <li key={r.id}>{r}</li>)}</ul>
    </div>
  );
}

推演：

1. 你输入了 “A”。
2. setInput('A') 立即执行。输入框显示 “A”。
3. startTransition 开始。
4. React 把 setQuery('A') 和 fetchResults 标记为低优先级。
5. 关键点来了！ 如果这时候你继续输入 “AB”。
6. setInput('AB') 立即执行。输入框显示 “AB”。
7. React 发现 setQuery('A') 还没执行完，但是 setQuery('AB') 已经进来了。
8. React 会丢弃 setQuery('A') 这个更新。
9. React 继续等待，直到 setQuery('AB') 准备好提交。
10. 如果在 setQuery('AB') 执行期间，你输入了 “ABC”，setQuery('AB') 又被丢弃了。

结论：
startTransition 确保了 UI 的响应性。它保证了 input 的值总是最新的（高优先级），而 query 和 results 总是“最后输入的那个值”，并且只有在当前没有更高优先级的输入时才会更新。这就是并发更新的精髓：用最新的状态覆盖旧的、未完成的状态。

第六部分：flushSync —— 强制执行的“暴君”

有时候，你不想让 React 插手，你想强制同步更新状态，不管它是不是高优先级，不管它会不会被中断。这时候，我们就需要 flushSync。

import { flushSync } from 'react-dom';

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

  const handleClick = () => {
    // 使用 flushSync 强制同步更新
    flushSync(() => {
      setCount(count + 1);
    });

    // 这里的代码会在 DOM 更新后立即执行
    console.log('Count 已经更新了');
  };

  return (
    <button onClick={handleClick}>
      Count: {count}
    </button>
  );
}

推演：

1. 点击按钮。
2. flushSync 拦截了 setCount。
3. React 强制立即执行这个更新，阻塞后续的高优先级任务。
4. count 变成 1。
5. 控制台打印 “Count 已经更新了”。
6. 然后才继续处理其他逻辑。

结论：
flushSync 是一把双刃剑。它能确保状态的一致性，但它会破坏并发模式带来的性能优势（因为它阻塞了主线程）。通常只在需要保证两个状态更新严格按顺序发生时才使用。

第七部分：实战演练 —— 一个防抖的搜索组件

好了，理论讲得差不多了，咱们来写个实战代码。我们要构建一个搜索组件，它需要处理输入、防抖（防止用户每敲一个字就发一次请求）、以及并发中断时的清理。

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

// 模拟 API 请求
const mockSearchAPI = async (query: string) => {
  console.log(`[API] 正在请求: ${query}`);
  await new Promise(resolve => setTimeout(resolve, 1000)); // 模拟网络延迟
  console.log(`[API] 请求完成: ${query}`);
  return [
    { id: 1, title: `${query} - 结果 1` },
    { id: 2, title: `${query} - 结果 2` },
  ];
};

function AdvancedSearch() {
  const [inputValue, setInputValue] = useState('');
  // 使用 useDeferredValue 将搜索词延迟更新
  // 这意味着 inputValue 变化很快，但 query 变化会被“节流”
  const query = useDeferredValue(inputValue);

  const [results, setResults] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  // 这个 Effect 依赖于 query，而不是 inputValue
  useEffect(() => {
    // 只有当 query 真正改变时才触发搜索
    if (!query) {
      setResults([]);
      return;
    }

    let cancelled = false; // 用于标记请求是否被取消

    const performSearch = async () => {
      setLoading(true);
      setError(null);

      try {
        const data = await mockSearchAPI(query);

        // 关键点：检查 cancelled 标志
        // 如果组件在请求期间被中断（例如输入了新词），这个请求就不再有效了
        if (cancelled) return;

        setResults(data);
      } catch (err) {
        if (!cancelled) setError(err.message);
      } finally {
        if (!cancelled) setLoading(false);
      }
    };

    performSearch();

    // 清理函数
    return () => {
      console.log(`[Cleanup] 取消搜索: ${query}`);
      cancelled = true;
    };
  }, [query]); // 依赖项是 query

  const handleChange = (e) => {
    const value = e.target.value;
    setInputValue(value);
    // 注意：这里不需要直接 setQuery，因为 useDeferredValue 会处理
  };

  return (
    <div style={{ padding: '20px' }}>
      <h2>并发搜索实战</h2>

      <input 
        value={inputValue} 
        onChange={handleChange} 
        placeholder="输入内容..." 
        style={{ fontSize: '20px', padding: '10px', marginBottom: '20px' }}
      />

      <div>
        {loading && <p>正在搜索: {query}...</p>}
        {error && <p style={{ color: 'red' }}>错误: {error}</p>}

        <ul>
          {results.map(item => (
            <li key={item.id}>{item.title}</li>
          ))}
        </ul>
      </div>
    </div>
  );
}

export default AdvancedSearch;

深度解析这段代码：

1. useDeferredValue 的作用：

   • 当你输入 “A” 时，inputValue 变成 “A”，UI 立即反馈。
   • query 变成 “A”，但是 useDeferredValue 告诉 React：“这个更新可以晚点做”。
   • 当你输入 “B” 时，inputValue 立即变成 “B”。query 变成 “B”。
   • React 看到 “A” 还没提交，”B” 进来了。React 丢弃 “A”，直接处理 “B”。
   • 这就是并发更新的状态清理逻辑：新状态覆盖旧状态。

2. Effect 中的 cancelled 标志：

   • 假设 “A” 的请求还在跑（1秒后返回），你输入了 “B”。
   • useEffect 的依赖项 [query] 变了，React 触发 Effect 的清理函数。
   • 清理函数执行，cancelled = true。
   • 1秒后，API 返回了 “A” 的数据。
   • setResults 执行。
   • 代码检查 if (cancelled) return;。
   • 结果： “A” 的数据被忽略了！这就是状态清理的终极体现。我们不需要手动取消网络请求（虽然取消请求是好的做法），我们只需要在更新状态前检查一下“我现在还在不在这个组件里”。

3. 用户体验：

   • 如果你输入很快，比如 “ABC”，界面上的输入框会显示 “ABC”。
   • 搜索结果只会显示 “C”（最后一次有效的请求）。
   • 这就是并发模式带给我们的流畅体验。

第八部分：深入 Fiber 树 —— 内部视角的清理

咱们再往深了挖一点。React 到底是怎么“中断”的？这涉及到 React 内部的 Fiber 架构。

当你调用 setState 时，React 并不是直接修改 DOM。它会在内存中构建一个更新队列。这个队列里包含了很多个“更新计划”。

然后，React 的调度器（Scheduler）会根据优先级来挑选这些计划。

渲染阶段：

1. React 遍历 Fiber 树。
2. 它执行组件函数，生成新的 JSX。
3. 它检查 useEffect，准备执行清理函数。
4. 中断点： 如果这时候来了一个高优先级任务，React 会扔掉当前的 Fiber 树遍历，回到根节点，重新开始。
5. 清理： 在重新开始之前，React 会执行所有被中断的 Effect 的清理函数。

提交阶段：

1. 当所有高优先级任务都处理完了，React 开始提交阶段。
2. 它会把变更应用到 DOM 上。
3. 注意： 在提交阶段，React 不允许中断。一旦开始更新 DOM，它必须一口气做完。
4. 如果你在 useEffect 里做任何操作，那都是在提交阶段之后执行的。这意味着，如果 Effect 里调用了 setState，这会触发一个新的渲染周期，这个新的渲染周期是安全的，不会被刚才的中断打断。

所以逻辑链条是：

1. 高优先级任务打断低优先级渲染。
2. React 运行低优先级组件的 Effect 清理函数。
3. React 运行高优先级组件的 Effect（如果有）。
4. React 开始提交阶段（DOM 更新）。
5. Effect 钩子运行（副作用）。

第九部分：常见的坑与避坑指南

讲到这里，我相信大家对并发更新有了很深的理解。但是，在实战中，有几个坑是大家经常踩的。

坑 1：在 Effect 中使用 setTimeout 设置状态

useEffect(() => {
  setTimeout(() => {
    setState(prev => prev + 1); // 危险！
  }, 1000);
}, []);

• 后果： 如果组件在 1 秒内被卸载，这个状态更新虽然不会报错，但它可能会在组件已经消失后依然触发重渲染（虽然 React 会检查挂载状态）。更糟糕的是，如果在并发模式下，这个更新可能会被其他更新覆盖，导致逻辑混乱。
• 建议： Effect 只负责副作用（数据获取、订阅），不要用它来驱动业务逻辑的状态更新。业务逻辑的状态更新应该在事件处理函数（onClick 等）中完成。

坑 2：忽略清理函数
很多开发者觉得清理函数只是用来 clearInterval 的。其实，它还可以用来取消未完成的 Promise。

useEffect(() => {
  let isMounted = true;
  const fetchData = async () => {
    const res = await api.get();
    if (isMounted) setData(res);
  };
  fetchData();
  return () => { isMounted = false; };
}, []);

这是一个经典的“防内存泄漏”模式。在并发模式下，isMounted 的作用更加关键，因为组件可能会被反复卸载和挂载。

坑 3：过度使用 flushSync
为了追求所谓的“同步感”，到处使用 flushSync。

• 后果： 用户体验变差。输入框可能不会即时响应，因为 flushSync 把主线程卡住了。
• 建议： 除非你有非常严格的业务需求（比如计算器必须保证按键和显示一一对应），否则不要使用 flushSync。

第十部分：总结与展望

好了，同学们，咱们今天的讲座也接近尾声了。

我们今天一起推演了 React 并发更新中断后的状态清理逻辑。从最简单的 setState 被丢弃，到复杂的 useEffect 清理函数执行，再到 startTransition 的优雅降级，以及 flushSync 的强制同步。

核心思想其实就一句话：React 是一个健忘的管家。

当高优先级的事情发生时，它会把低优先级的账本扔掉（状态更新被中断），它会清理掉低优先级管家留下的烂摊子（Effect 清理函数），然后全心全意去处理高优先级的事情。

对于开发者来说，这意味着：

1. 你的代码必须具备“幂等性”。多次调用 setState 不会产生副作用，只会产生最终结果。
2. 你的 Effect 必须有清理函数，以应对组件的中断、卸载和重新挂载。
3. 利用 startTransition 和 useDeferredValue 来区分“重要”和“不重要”的更新。

并发模式不是为了让代码变难写，而是为了让代码跑得更快、更流畅。只要你理解了它的中断和清理机制，你就能写出像丝般顺滑的 React 应用。

好了，今天的课就到这里。下课！记得把你们的 clearInterval 写上！