深入 ‘Synchronous Flush’：在哪些极端边缘场景下，React 必须强迫并发模式转为同步阻塞模式？

各位同学，下午好。

今天，我们将深入探讨 React 并发模式（Concurrent Mode）中的一个核心但又常常被误解的概念：同步刷新（Synchronous Flush）。React 的并发模式旨在通过可中断的渲染、时间切片和优先级调度，为用户提供流畅、响应迅速的应用体验。它承诺将耗时的渲染工作分解成小块，在必要时暂停，让浏览器有机会处理用户输入或动画，从而避免主线程阻塞。

然而，在某些极端边缘场景下，React 不得不放弃其并发的理想，转而强迫执行同步阻塞模式来完成 DOM 更新。这些场景是 React 设计中的“安全阀”或“逃生舱”，它们的存在是为了确保应用程序在特定关键时刻的正确性、即时响应或与浏览器行为的兼容性。作为一名专业的开发者，理解这些场景，不仅能帮助我们更好地调试性能问题，更能指导我们编写出更健壮、更符合预期的 React 应用。

React 的渲染与提交机制：快速回顾

在深入同步刷新之前，我们有必要快速回顾一下 React 的工作流程，特别是其渲染（Render）和提交（Commit）阶段。

1. 渲染阶段（Render Phase / Reconciliation）：

   • 这是一个纯计算阶段，React 在此阶段构建或更新其“虚拟 DOM”——实际上是 Fiber 树。
   • 它根据组件的 state 和 props 计算出新的 UI 结构。
   • 关键特性：可中断、可暂停、可恢复、甚至可以被丢弃重做。React 可以将渲染工作切片，分批执行，在每一小块工作完成后，检查是否有更高优先级的任务（如用户输入），并让出主线程。这意味着渲染阶段本身不会阻塞浏览器。

2. 提交阶段（Commit Phase）：

   • 这是一个副作用阶段，React 在此阶段将渲染阶段计算出的所有变更（DOM 的增删改、属性更新等）一次性地应用到真实的浏览器 DOM 上。
   • 同时，在这个阶段，React 还会执行生命周期方法（如类组件的 componentDidMount / componentDidUpdate / componentWillUnmount）以及 Hook（如 useLayoutEffect 和 useEffect）。
   • 关键特性：不可中断、同步执行。一旦开始，就必须完成，直到所有的 DOM 变更都应用完毕。这是因为对真实 DOM 的操作涉及到浏览器布局（layout）和绘制（paint），中断这些操作会导致不一致或视觉闪烁。

在并发模式下，React 会尽可能地将渲染阶段的工作调度到后台，利用浏览器的空闲时间（通过 requestIdleCallback 的概念模型，实际实现通常通过 MessageChannel）。而提交阶段，尽管其本身是同步的，但 React 仍然希望它尽可能地短，以最大限度地减少主线程的阻塞时间。

那么，“同步刷新”究竟意味着什么？它指的是 React 不得不跳过正常的调度机制，立即执行渲染阶段（或至少是其大部分工作），然后紧接着执行提交阶段，整个过程阻塞主线程，直到 DOM 更新完成。这通常发生在 React 认为某个更新具有极高的优先级，或者必须在特定时刻完成，否则会导致应用程序逻辑错误、视觉不一致或用户体验严重受损。

并发模式的理想流动与同步异常

并发模式的理想流动：

在一个理想的并发世界中，React 会将更新分为不同的优先级。例如，用户输入（如文本框输入）是高优先级的，需要快速响应；而数据加载后的列表渲染可能是低优先级的，可以延迟或在后台进行。

1. 调度更新：当 setState 或 useReducer 被调用时，React 会根据更新的来源和上下文给它一个优先级。
2. 异步渲染：React 的调度器 (Scheduler) 将渲染工作分解成小块，并使用 MessageChannel 或其他异步机制将其排入浏览器的宏任务队列。
3. 可中断性：在每一小块渲染工作之后，React 会检查是否有更高优先级的任务（例如新的用户输入）。如果有，它会暂停当前渲染，让出主线程给浏览器处理更高优先级的任务。
4. 最终提交：当渲染阶段的所有工作（或至少是当前优先级的全部工作）完成，并且没有更高优先级的任务打断时，React 会进入同步的提交阶段，将变更应用到 DOM。
5. 浏览器绘制：提交完成后，浏览器会执行布局和绘制，将新的 UI 呈现给用户。

同步异常：强迫同步刷新的场景

现在，我们来看那些不得不打破上述理想流动的“极端边缘场景”。这些场景可以大致分为以下几类：

1. 遗留 API 集成与浏览器约束

React 的发展历史悠久，它需要兼容旧的 API 和浏览器固有的工作机制。在这些情况下，并发模式的优势可能无法完全发挥，甚至被完全绕过。

a. ReactDOM.render() (遗留根 API)

这是最直接且最常见的同步刷新场景。在 React 18 之前，我们通常使用 ReactDOM.render() 来初始化 React 应用。

import React from 'react';
import ReactDOM from 'react-dom';

function LegacyApp() {
  const [count, setCount] = React.useState(0);

  React.useEffect(() => {
    console.log('App mounted, count:', count);
  }, [count]);

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

const rootElement = document.getElementById('root');
// 这里的 ReactDOM.render() 会立即、同步地挂载并刷新组件到 DOM。
// 即使在 React 18 环境下，使用这个 API 也会强制整个子树以遗留的、同步的方式渲染。
ReactDOM.render(<LegacyApp />, rootElement);

// 在 ReactDOM.render 调用之后，DOM 已经同步更新完毕。
console.log('Root element content after render:', rootElement.innerHTML);

解释：
ReactDOM.render() 是 React 18 之前创建 React 根的入口。它被设计为立即将组件挂载到 DOM 并进行渲染。它不具备并发模式的能力。当你调用 ReactDOM.render() 时，React 会执行以下步骤：

1. 同步地创建应用的 Fiber 树。
2. 同步地执行所有组件的渲染逻辑。
3. 同步地将所有 DOM 变更应用到真实的浏览器 DOM。
4. 同步地执行 useLayoutEffect。
5. 最后，在下一个微任务或宏任务中调度 useEffect。

整个过程是阻塞的，直到初始渲染完成。在 React 18 中，推荐使用 ReactDOM.createRoot() 来启用并发特性。但为了兼容性，ReactDOM.render() 仍然存在，并且其行为保持同步，因此它是一个明确的同步刷新点。

b. useLayoutEffect 中对 DOM 尺寸的同步读取和更新

useLayoutEffect 是 React 提供的一个 Hook，它的执行时机非常特殊：在所有 DOM 变更完成后，但在浏览器绘制（paint）之前，它是同步执行的。这使得它非常适合进行 DOM 测量或需要立即同步修改 DOM 的场景。

然而，如果 useLayoutEffect 内部需要读取的 DOM 属性（例如 offsetWidth, offsetHeight, getBoundingClientRect() 的结果）依赖于当前正在等待提交的某个状态更新，那么 React 必须确保该状态更新所对应的 DOM 变更已经完成，才能提供正确的值。这就会强制 React 立即完成任何正在进行的、会影响这些 DOM 属性的渲染和提交工作。

考虑一个工具提示（Tooltip）组件，它需要根据其目标元素的位置来定位自身：

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

function Tooltip({ targetRef, children }) {
  const tooltipRef = useRef(null);
  const [position, setPosition] = useState({ top: 0, left: 0 });
  const [isVisible, setIsVisible] = useState(false);

  // 假设 targetRef.current 对应的元素会因为某个状态更新而改变大小或位置
  // 并且这个 Tooltip 组件的渲染是紧随其后的
  useLayoutEffect(() => {
    if (targetRef.current && tooltipRef.current && isVisible) {
      const targetRect = targetRef.current.getBoundingClientRect();
      const tooltipRect = tooltipRef.current.getBoundingClientRect();

      // 计算 Tooltip 位置
      const newTop = targetRect.top - tooltipRect.height - 10; // 向上偏移10px
      const newLeft = targetRect.left + (targetRect.width - tooltipRect.width) / 2;

      // 如果计算出的位置与当前状态不符，更新状态
      // 这里的 setState 会触发一次新的渲染。
      // 如果这个渲染又需要立即读取 DOM (例如，如果 Tooltip 的内容在这次更新中改变了大小)，
      // 那么 React 可能会被迫同步刷新，以确保 useLayoutEffect 在下一轮得到正确 DOM。
      // 这里的关键是：useLayoutEffect 运行在 DOM 变更之后、浏览器绘制之前。
      // 如果有任何 pending 的 DOM 变更（即使是较低优先级的），
      // 并且 useLayoutEffect 依赖于这些变更后的 DOM 状态，
      // React 必须先同步完成这些变更。
      if (newTop !== position.top || newLeft !== position.left) {
        setPosition({ top: newTop, left: newLeft });
      }
    }
  }, [targetRef, isVisible, position]); // position 作为依赖项，避免无限循环

  return isVisible ? (
    <div
      ref={tooltipRef}
      style={{
        position: 'absolute',
        top: position.top,
        left: position.left,
        backgroundColor: 'black',
        color: 'white',
        padding: '5px',
        borderRadius: '3px',
        zIndex: 1000,
      }}
    >
      {children}
    </div>
  ) : null;
}

function ParentComponent() {
  const targetRef = useRef(null);
  const [text, setText] = useState('Hover over me!');

  // 模拟一个可能改变目标元素大小的更新
  const toggleText = () => {
    setText(prev => (prev === 'Hover over me!' ? 'A bit longer text now!' : 'Hover over me!'));
  };

  return (
    <div style={{ padding: '50px' }}>
      <button onClick={toggleText}>Toggle Target Text</button>
      <p
        ref={targetRef}
        style={{ border: '1px solid blue', padding: '10px', display: 'inline-block' }}
        onMouseEnter={() => console.log('Mouse Enter')} // 实际场景会在这里显示 Tooltip
        onMouseLeave={() => console.log('Mouse Leave')} // 实际场景会在这里隐藏 Tooltip
      >
        {text}
      </p>
      {/* 这里的 Tooltip 会在 targetRef 发生变化时重新计算位置 */}
      {/* 假设我们通过某种方式控制 Tooltip 的 isVisible 状态 */}
      <Tooltip targetRef={targetRef} isVisible={true}>
        This is a dynamic tooltip!
      </Tooltip>
    </div>
  );
}

深入分析 useLayoutEffect 强制同步刷新：

useLayoutEffect 本身是同步执行的，它运行在提交阶段。当 React 决定执行一个 useLayoutEffect 时，它会确保所有当前渲染批次的 DOM 变更已经应用到 DOM。

然而，“极端边缘场景”出现在以下情况：

1. 存在一个正在进行中的、优先级可能较低的并发渲染。
2. 这个并发渲染会更新 DOM，并影响到某个元素的布局属性（如尺寸、位置）。
3. 紧接着，应用程序触发了一个新的、需要立即读取 DOM 的 useLayoutEffect（例如，某个高优先级事件触发了 setState，导致一个组件重新渲染，并且这个组件内部有 useLayoutEffect）。
4. 为了确保这个 useLayoutEffect 读取到的是最新的、正确的 DOM 状态（即包含了步骤 2 中变更的 DOM 状态），React 可能会被迫中断当前的并发渲染，并同步地完成所有影响到该 useLayoutEffect 所需 DOM 的挂起更新。

如果不这样做，useLayoutEffect 就会读取到过时的 DOM 状态，导致计算错误，进而引发视觉错位或“布局抖动”（layout thrashing）。这种强制同步，是为了保证逻辑的正确性和视觉的一致性，防止在浏览器绘制前出现不正确的中间状态。

布局抖动（Layout Thrashing）：
一个典型的导致同步刷新的 useLayoutEffect 滥用模式是，在 useLayoutEffect 中读取 DOM 属性，然后根据这些属性更新状态，而这个状态更新又导致了组件的重新渲染，并再次触发 useLayoutEffect。如果处理不当，这可能形成一个无限循环，每次循环都强制 React 进行同步的 DOM 读取和写入，从而严重阻塞主线程。

function BadLayoutEffectComponent() {
  const [height, setHeight] = useState(0);
  const ref = useRef(null);

  useLayoutEffect(() => {
    if (ref.current) {
      const currentHeight = ref.current.offsetHeight;
      if (currentHeight !== height) {
        // 这里的 setState 会触发一次新的渲染。
        // 如果在新的渲染中，DOM 结构发生了变化，
        // 并且在下一个 useLayoutEffect 再次读取之前，
        // React 需要确保 DOM 已经更新。
        // 这种模式可能导致多次同步刷新和布局抖动。
        setHeight(currentHeight);
      }
    }
  }); // 注意：没有依赖数组，每次渲染后都运行。非常危险！

  return (
    <div ref={ref} style={{ border: '1px solid red', padding: '10px' }}>
      <p>This content's height is {height}px.</p>
      {/* 想象这里的内容会动态变化，导致高度变化 */}
    </div>
  );
}

在这个例子中，setHeight(currentHeight) 会触发一个新的渲染。由于 useLayoutEffect 没有依赖数组，它会在每次渲染后运行。如果 currentHeight 确实与 height 不同，setHeight 会再次触发渲染。这个循环会不断地强制 React 在 useLayoutEffect 内部进行 DOM 读取（offsetHeight）和随后的 DOM 更新（通过 setHeight 触发的渲染和提交），从而导致连续的同步刷新和布局抖动，严重影响性能。

2. 紧急更新与事件处理

某些用户交互或应用程序逻辑要求即时响应和 DOM 更新，以避免视觉延迟或逻辑错误。

a. ReactDOM.flushSync() (显式强制同步刷新)

这是 React 专门提供的一个“逃生舱”，允许开发者主动、明确地强制 React 同步地完成所有挂起的渲染和提交工作。这是你在需要确保 DOM 立即更新，以便执行依赖于最新 DOM 状态的同步操作时使用的。

import React, { useState, useRef } from 'react';
import { flushSync } from 'react-dom'; // 从 react-dom 导入 flushSync

function ForcedSyncExample() {
  const [count, setCount] = useState(0);
  const displayRef = useRef(null);

  const handleClick = () => {
    // 强制同步更新状态并刷新到 DOM
    flushSync(() => {
      setCount(prevCount => prevCount + 1);
    });

    // 在 flushSync 之后，DOM 保证已经更新。
    // 我们可以立即读取最新的 DOM 内容。
    console.log('DOM updated immediately. Current count in DOM:', displayRef.current.textContent);

    // 假设这里有一些依赖于最新 DOM 状态的第三方库操作
    // 例如，一个动画库需要获取元素的新位置
    // someThirdPartyAnimationLibrary.animate(displayRef.current, { x: newX });

    // 如果没有 flushSync，这里的 console.log 和第三方库操作
    // 可能会读取到旧的 DOM 状态，因为 React 可能会异步调度 setCount 的更新。
  };

  return (
    <div>
      <p ref={displayRef}>Count: {count}</p>
      <button onClick={handleClick}>Increment (Forced Sync)</button>
      <p>
        <small>Watch console for immediate DOM read.</small>
      </p>
    </div>
  );
}

解释：
当你将状态更新包裹在 flushSync 中时，React 会立即处理该更新，执行渲染阶段和提交阶段，整个过程是阻塞的。这意味着在 flushSync 闭包结束后，你所做的状态更改已经反映在真实的 DOM 上。

使用场景：

• 与第三方 DOM 库集成：当你需要与直接操作 DOM 的第三方库（如一些动画库、地图库或富文本编辑器）交互时，这些库通常期望 DOM 处于特定状态。flushSync 可以确保 React 的更新在这些库操作之前完成。
• 精确的动画控制：在某些复杂的动画场景中，可能需要在一帧内完成多个 DOM 测量和修改，以避免视觉跳动。flushSync 可以确保测量是在最新状态的 DOM 上进行的。
• 处理浏览器事件的默认行为：如果你需要在某个事件处理器中阻止浏览器的默认行为 (e.preventDefault())，并且该行为的阻止依赖于 React 状态的即时更新，那么 flushSync 可能是有用的。
• 紧急修复视觉问题：在极少数情况下，为了修复一个难以通过其他方式解决的视觉故障，可能需要临时使用 flushSync。

警告：
flushSync 应该被视为“逃生舱”，极少使用。滥用它会消除并发模式的优势，导致主线程阻塞，降低应用的响应性。它应该只在你明确知道为什么需要它，并且没有其他异步替代方案时使用。

b. 高优先级事件处理（部分场景）

在 React 18 中，大多数事件回调中的 setState 都会被自动批处理（automatic batching），并可能被调度为并发更新。然而，在某些极端情况下，尤其是涉及到浏览器原生行为或需要立即视觉反馈的场景，React 可能会选择以更高的优先级，甚至同步的方式处理更新。

例如，在受控组件中处理 input 事件，如果 onChange 处理器中的状态更新不立即反映到 DOM，用户可能会感知到输入延迟或光标跳动。React 内部的事件系统会尽可能优化这些，但底层可能仍有同步的优先级处理以确保流畅的用户体验。

虽然 React 18 致力于使这些更新尽可能地并发，但在某些紧急情况下，例如：

• 在 onClick 或 onKeyDown 处理器中，如果你在更新状态后立即需要读取 DOM 属性，React 可能会优先处理这个更新。
• 如果一个事件处理器中的更新会导致一个 useLayoutEffect 运行，而该 useLayoutEffect 又需要读取最新的 DOM 状态，那么如前所述，它可能间接强制同步刷新。

这些场景通常不会直接暴露给开发者，而是 React 内部调度器为了维护用户体验和逻辑正确性而做出的决策。

3. 关键生命周期与副作用的相互依赖

React 的生命周期和 Hook 的执行顺序是严格定义的。当这些顺序与 DOM 的实时状态产生紧密耦合时，就可能导致同步刷新的需求。

a. useLayoutEffect 的强制性 (再次强调)

我们已经讨论了 useLayoutEffect 在测量 DOM 时的同步特性。这里再次强调其在强制同步刷新中的关键作用。useLayoutEffect 的设计意图就是提供一个在浏览器绘制前修改 DOM 的机会。如果它所依赖的 DOM 状态是未提交的（即仍然在某个挂起的并发渲染中），那么 React 必须强制刷新这些挂起的变更，以确保 useLayoutEffect 看到的是最新且正确的 DOM。

例如，一个需要根据其父元素宽度动态调整自身宽度的组件。

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

function ResizableChild({ parentRef }) {
  const [width, setWidth] = useState(0);
  const childRef = useRef(null);

  useLayoutEffect(() => {
    if (parentRef.current) {
      // 假设 parentRef.current 的宽度刚刚因为某个状态更新而改变
      // React 必须确保父元素的宽度在此时已经反映到 DOM 上，
      // 否则 childRef 就会根据旧的父元素宽度进行计算，导致错位。
      const parentWidth = parentRef.current.offsetWidth;
      const newWidth = parentWidth * 0.8; // 子元素占父元素的 80%

      if (newWidth !== width) {
        // 这里的 setState 可能会导致新的渲染，如果新渲染又需要 useLayoutEffect 再次测量，
        // 并且有其他 pending 的 DOM 变化，就可能触发同步刷新。
        setWidth(newWidth);
      }
    }
  }, [parentRef, width]); // 依赖 width 避免无限循环

  return (
    <div ref={childRef} style={{ width: `${width}px`, height: '50px', backgroundColor: 'lightblue', border: '1px solid black' }}>
      Child ({width}px)
    </div>
  );
}

function ParentComponentWithDynamicWidth() {
  const parentRef = useRef(null);
  const [dynamicWidth, setDynamicWidth] = useState(200);

  // 模拟一个动态改变父元素宽度的按钮
  const increaseWidth = () => {
    setDynamicWidth(prev => prev + 50);
  };

  return (
    <div style={{ padding: '20px' }}>
      <button onClick={increaseWidth}>Increase Parent Width</button>
      <div
        ref={parentRef}
        style={{
          width: `${dynamicWidth}px`,
          height: '100px',
          backgroundColor: 'lightgray',
          border: '2px dashed purple',
          marginTop: '20px',
          display: 'flex',
          alignItems: 'center',
          justifyContent: 'center',
        }}
      >
        Parent ({dynamicWidth}px)
        <ResizableChild parentRef={parentRef} />
      </div>
    </div>
  );
}

在这个例子中，当 ParentComponentWithDynamicWidth 的 dynamicWidth 状态更新时，ResizableChild 会重新渲染。ResizableChild 内部的 useLayoutEffect 会立即执行，并尝试读取 parentRef.current.offsetWidth。为了确保 useLayoutEffect 读取到的是 dynamicWidth 更新后的父元素宽度，React 必须在 useLayoutEffect 运行之前，同步地将 ParentComponentWithDynamicWidth 的宽度更新提交到 DOM。这正是 useLayoutEffect 强制同步刷新的一个典型场景。

4. 水合作用 (Hydration)

当使用服务器端渲染（SSR）或静态站点生成（SSG）时，浏览器会接收到已经渲染好的 HTML。React 在客户端启动时，会尝试“水合”（hydrate）这个静态 HTML，将其转化为一个交互式的 React 应用。

a. ReactDOM.hydrate() (遗留) 和 ReactDOM.hydrateRoot() (并发)

水合作用是将 React 的事件监听器和其他内部状态附加到已存在的 DOM 结构上的过程。在这个过程中，React 会尝试将服务器端生成的 DOM 结构与客户端的 React 组件树进行匹配。

• 初始匹配和事件附加：尽管 React 18 的 hydrateRoot 旨在使水合过程更具可中断性，但初始阶段，尤其是将事件监听器附加到根元素以及验证关键 DOM 结构时，仍然是高度优先级的，并且可能包含同步阻塞的部分。如果客户端 React 组件树与服务器端渲染的 HTML 结构不匹配（hydration mismatch），React 可能会被迫抛弃服务器端 HTML，并在客户端重新同步渲染整个组件树，这会是一个完全的同步刷新，并导致性能下降和用户体验问题（例如内容闪烁）。

// 客户端入口文件
import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

const rootElement = document.getElementById('root');

// 在 React 18 之前，使用 ReactDOM.hydrate()
// 这是一个同步操作，会阻塞主线程直到水合完成。
// ReactDOM.hydrate(<App />, rootElement);

// 在 React 18 中，推荐使用 ReactDOM.hydrateRoot()
// 它尝试进行可中断的水合，但初始阶段和不匹配时仍可能强制同步。
const root = ReactDOM.hydrateRoot(rootElement, <App />);
// root.render(<App />); // 如果需要后续更新，可以在这里调用 render

// 即使使用 hydrateRoot，如果初始组件结构与服务器端 HTML 存在严重不匹配，
// React 也可能在内部退化为同步的重新渲染，以确保应用的正确性。

解释：
水合作用的目标是让用户尽快看到内容（从服务器端 HTML），并尽快使其可交互。为了实现“尽快可交互”的目标，React 必须同步地将事件处理器附加到 DOM 元素上。如果在这个过程中发现 DOM 结构与 React 的预期不符，React 别无选择，只能同步地重新渲染受影响的部分，以修正这种不一致。这种修正过程是阻塞的，因为它涉及到 DOM 的增删改。React 18 的并发水合可以中断 渲染 阶段，但 提交 阶段（包括事件附加和 DOM 更新）仍然是同步的。如果水合过程中发现严重的 DOM 不匹配，导致需要重新渲染，那么这个重新渲染的提交阶段仍然会是同步且阻塞的。

React 如何管理同步刷新 (内部机制)

React 内部使用一套复杂的优先级和调度系统来决定何时以及如何执行更新。

• 优先级模型 (Lane Model)：React 18 引入了 Lane 模型来管理不同更新的优先级。例如，用户输入（如 click 事件）通常被赋予最高优先级（SyncLane 或 InputContinuousLane），而 startTransition 触发的更新则被赋予较低的优先级（TransitionLane）。当一个高优先级的更新到达时，它会中断当前正在进行的较低优先级的渲染工作，并被优先处理。
• Scheduler 模块：React 的 Scheduler 模块负责将工作（渲染、效果）排入浏览器的事件循环。对于并发工作，它通常使用 MessageChannel 来创建宏任务，从而实现在每个任务块之间让出主线程。
• flushSync 的实现：当调用 flushSync 时，它会创建一个具有最高优先级（SyncLane）的更新，并指示调度器立即执行它，绕过正常的异步调度。这会强制 React 执行 performSyncWorkOnRoot 或类似的内部函数，从而同步完成渲染和提交。
• useLayoutEffect 的时机：useLayoutEffect 在提交阶段同步运行，在所有的 DOM 变更之后、浏览器绘制之前。它的同步特性，以及它对 DOM 实时状态的依赖，是其能够强制同步刷新的核心原因。如果 useLayoutEffect 依赖于一个尚未提交的 DOM 状态，React 必须先同步提交该状态，再执行 useLayoutEffect。

后果与最佳实践

同步刷新的后果

1. 阻塞主线程：这是最直接也是最严重的后果。主线程被阻塞意味着浏览器无法处理用户输入、无法更新动画、无法响应其他事件，导致 UI 卡顿、无响应。
2. 视觉卡顿 (Jank)：用户会感知到页面不流畅，动画不连贯，或者点击按钮后没有即时反馈。
3. 布局抖动 (Layout Thrashing)：如果频繁地在同步代码块中读取 DOM 布局属性（如 offsetWidth）然后立即修改 DOM（如 element.style.width = ...），再重复此过程，会导致浏览器反复计算布局，极大地降低性能。
4. 性能下降：虽然某些同步刷新是必要的，但过多的或不必要的同步刷新会抵消并发模式带来的性能优势，导致应用整体响应变慢。

避免或慎用同步刷新的最佳实践

1. 优先使用 useEffect：

   • useEffect 在浏览器绘制后异步执行，不会阻塞主线程。
   • 只有当你确实需要同步测量 DOM 或执行会在浏览器绘制前改变 DOM 布局的操作时，才考虑 useLayoutEffect。
   • 始终问自己：“这个副作用是否必须在浏览器绘制之前发生？”如果不是，就用 useEffect。

2. 谨慎使用 useLayoutEffect：

   • 避免在 useLayoutEffect 中触发状态更新，尤其是那些会导致 DOM 尺寸或位置发生变化的更新，这很容易导致布局抖动。
   • 如果必须在 useLayoutEffect 中更新状态，请确保你有严格的条件来防止无限循环，并尽量将更新最小化。
   • 确保 useLayoutEffect 的依赖数组尽可能精准，避免不必要的重复执行。

3. 避免滥用 ReactDOM.flushSync()：

   • 将其视为最后的手段。在需要与非 React DOM 操作库集成，或进行极其精密的动画控制时才考虑。
   • 在使用 flushSync 时，尽量将它包裹的代码块保持精简，确保只包含必须同步执行的逻辑。

4. 利用 React 18 的并发特性：

   • ReactDOM.createRoot() / ReactDOM.hydrateRoot()：总是使用新的根 API，以启用并发模式和自动批处理。
   • startTransition：对于非紧急的 UI 更新（例如根据搜索结果更新列表），将其包裹在 startTransition 中，让 React 可以中断这些更新，优先处理用户输入。
   • useDeferredValue：如果某个值在变化时会导致昂贵的渲染，但你希望用户看到旧值直到新值准备好，可以使用 useDeferredValue 来推迟其更新。

5. 优化 DOM 操作：

   • 尽量减少直接的 DOM 操作。
   • 批量读取和写入 DOM。如果需要在短时间内进行多次 DOM 测量和修改，尽量先一次性读取所有需要的测量值，然后一次性应用所有修改。
   • 使用 CSS 动画和转换代替 JavaScript 驱动的动画，因为浏览器可以对 CSS 动画进行优化，通常在合成线程上执行，不阻塞主线程。

6. 正确处理水合作用 (Hydration)：

   • 确保服务器端渲染的 HTML 与客户端 React 组件树结构完全一致，以避免水合不匹配导致的客户端重新渲染。
   • 使用 React DevTools 检查水合警告。

总结

React 的同步刷新机制是其设计中不可或缺的一部分，它在保证应用程序正确性、即时响应和与浏览器兼容性方面扮演着关键角色。理解这些极端边缘场景——从遗留 API 的强制性到 useLayoutEffect 的精确时机，再到 flushSync 的显式干预以及水合作用的特殊需求——对于构建高性能、稳定的 React 应用至关重要。虽然并发模式是未来的方向，但这些同步的“安全阀”提醒我们，在某些关键时刻，牺牲部分并发性以确保核心功能的正确执行，是不可避免的工程权衡。作为开发者，我们的任务是明智地识别这些场景，并在必要时使用这些同步工具，同时最大限度地利用 React 的并发能力，为用户提供卓越的体验。