什么是 ‘React Content Persistence’？在大型编辑器应用中如何保持撤销/重做后的 Fiber 节点复用 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

在大型编辑器应用中，用户期望流畅、无缝的交互体验，其中撤销/重做功能是不可或缺的。然而，在 React 应用中实现高效且状态保持的撤销/重做，特别是要确保 Fiber 节点的复用，是一个复杂但至关重要的挑战。今天，我们将深入探讨 ‘React Content Persistence’ 这一概念，以及如何在撤销/重做操作中最大限度地复用 Fiber 节点，从而提升性能和用户体验。

1. React Content Persistence 的核心概念

“React Content Persistence” 指的是在 React 应用中，当底层数据模型发生变化（例如用户编辑、撤销、重做），或者组件树因某些原因重新渲染时，能够尽可能地保持 DOM 元素和其对应的 React 组件实例（以及它们内部的状态，即 Fiber 节点）的稳定性和连续性。

在大型编辑器应用中，这尤为关键：

用户体验： 如果每次撤销/重做都导致整个编辑器内容重新挂载（re-mount），用户会看到闪烁、焦点丢失、滚动位置重置等问题，极大损害用户体验。
性能： 大规模的 DOM 重新创建和销毁是昂贵的。重新挂载组件意味着重新运行所有生命周期方法、Effect Hooks、以及重新初始化所有内部状态，这会造成显著的性能开销。
状态管理： 组件内部可能持有许多瞬态的 UI 状态，例如文本输入框的焦点、选区、滚动位置、一个可拖拽元素的拖拽状态，甚至是一个视频播放器的播放进度。如果组件被重新挂载，这些瞬态状态将全部丢失。

因此，React Content Persistence 的核心目标是：在数据模型更新时，通过智能的协调（reconciliation）机制，让 React 尽可能地更新现有组件实例和 DOM 元素，而不是销毁旧的并创建新的。 对于撤销/重做场景，这意味着我们希望 React 能够识别出“这是同一个内容块，只是数据变了”，而不是“这是一个全新的内容块”。

2. React 的协调机制与 Fiber 架构

要理解如何实现内容持久化，我们首先需要回顾 React 的核心工作原理。

2.1 虚拟 DOM (Virtual DOM)

React 不直接操作真实的浏览器 DOM。它维护一个轻量级的 JavaScript 对象树，称为虚拟 DOM。当组件的状态或属性发生变化时，React 会创建一个新的虚拟 DOM 树，并将其与前一个虚拟 DOM 树进行比较。

2.2 协调（Reconciliation）过程

协调是 React 确定如何高效更新真实 DOM 的过程。它遵循一套启发式算法：

比较根元素： 如果根元素类型不同，React 会销毁旧树并从头开始构建新树。
比较同类型元素： 如果根元素类型相同，React 会保留现有 DOM 节点，只更新其属性。
比较子元素： 默认情况下，React 会按顺序比较子元素。如果子元素列表发生变化（增删改），React 会尽量复用现有的 DOM 节点。

2.3 Fiber 架构的引入

在 React 16 之后，引入了 Fiber 架构。Fiber 是对 React 核心协调算法的重写，其目标是实现可中断、可恢复、优先级驱动的更新。

什么是 Fiber 节点？

每个 React 元素（例如 <div /> 或 <MyComponent />）在渲染过程中都会对应一个 Fiber 节点。Fiber 节点是 React 内部表示组件工作单元的数据结构。它包含了：

类型 (type): 元素的类型，例如 'div' 或 MyComponent 函数/类。
键 (key): 用于在兄弟节点中唯一标识元素的字符串。
Props: 传递给组件的属性。
State: 组件的内部状态（对于类组件是 this.state，对于函数组件是 Hooks 状态）。
Child/Sibling/Return: 指向其子节点、兄弟节点和父节点的指针，构成了 Fiber 树。
alternate: 指向“旧” Fiber 树中对应节点的指针（current Fiber 树和 workInProgress Fiber 树之间的切换）。

Fiber 节点与实例的关联：

对于原生 DOM 元素（如 <div>），Fiber 节点会持有一个指向真实 DOM 节点的引用。
对于类组件，Fiber 节点会持有一个指向组件实例的引用（this）。
对于函数组件，Fiber 节点会关联其 Hooks 状态（useState、useRef 等）。

Fiber 的核心作用：

Fiber 架构允许 React 在后台构建一个“工作中的”（workInProgress）Fiber 树，而不会阻塞主线程。当工作完成时，整个 workInProgress 树会原子性地替换掉当前的 current 树，从而高效地更新 UI。

Fiber 与内容持久化的关联：

关键在于： 如果 React 决定复用一个 Fiber 节点（即该 Fiber 节点从 current 树被复制到 workInProgress 树，并进行更新），那么该 Fiber 节点所关联的组件实例、其内部状态（包括 Hooks 状态）、DOM 节点引用等都将被保留。反之，如果 React 决定销毁一个 Fiber 节点并创建一个新的，那么所有与旧 Fiber 节点相关联的内部状态都将丢失。

因此，为了实现内容持久化，我们的目标是：在撤销/重做过程中，设计组件结构和数据模型，使得 React 的协调算法能够尽可能地复用现有的 Fiber 节点，而不是销毁重建。

3. 大型编辑器中撤销/重做的挑战

在大型编辑器（如富文本编辑器、代码编辑器）中，撤销/重做面临的挑战更为严峻：

复杂的数据模型： 编辑器内容通常不是简单的字符串，而是由不同类型的块（段落、标题、图片、列表）、内联样式（粗体、斜体）、链接、自定义组件等组成的复杂树状或扁平结构。
瞬态 UI 状态： 除了内容本身，还有许多瞬态的 UI 状态需要维护：
- 光标位置和选区： 这是用户交互的核心，丢失会导致体验灾难。
- 滚动位置： 用户在长文档中编辑时，撤销后突然跳到顶部是不可接受的。
- 内部组件状态： 例如，一个图片组件可能有一个 isResizing 状态，一个代码块可能有一个 showLineNumbers 状态，一个可折叠区域可能有一个 isCollapsed 状态。这些都是组件内部独立管理的。
- 焦点状态： 哪个元素当前拥有焦点？
性能敏感性： 编辑器通常需要处理大量内容，每次操作都不能引起卡顿。
原子性操作： 撤销/重做操作通常需要是原子的，即要么完全恢复到上一步，要么不操作。

传统的撤销/重做实现通常采用两种模式：

命令模式 (Command Pattern): 记录一系列可逆的操作（do 和 undo）。
快照模式 (Snapshot Pattern): 在每个关键点保存整个应用状态的副本。

在 React 中，快照模式更常见，因为它简化了状态管理。我们保存一个完整的数据模型快照，在撤销/重做时替换当前数据模型，然后让 React 重新渲染。但关键问题是：当数据模型被替换时，React 如何在不销毁所有现有 Fiber 节点和 DOM 元素的情况下，高效地更新 UI？

4. 确保 Fiber 节点复用的策略

为了在撤销/重做后保持 Fiber 节点复用，我们需要结合 React 自身的设计原则和一些高级技巧。

4.1. 稳定 `key` 属性的威力

这是 React 协调机制中最重要的优化手段之一。

概念： 当渲染一个列表时，React 使用 key 属性来识别列表中哪些项发生了变化、添加或删除。key 帮助 React 建立列表中元素在不同渲染之间的身份映射。
对 Fiber 复用的影响：
- 如果列表中的某个元素没有 key 或 key 不稳定，当列表项的顺序发生变化时，React 可能会简单地销毁旧的 DOM 节点并重新创建新的，即使它们内容相同。
- 如果每个列表项都有一个稳定且唯一的 key，当列表项的顺序变化时，React 会尝试通过移动现有 DOM 节点来匹配 key，而不是销毁重建。
- 如果 key 相同但 type 不同（例如，一个 <div> 变成了 <p>），React 仍然会销毁旧的 Fiber 节点并创建新的。
- 如果 key 和 type 都相同，React 会复用 Fiber 节点和关联的 DOM 元素，只更新其属性和子节点。
在编辑器中的应用：
- 块级内容： 编辑器中的每个独立内容块（段落、标题、图片、列表项等）都应该拥有一个全局唯一且稳定的 key。通常使用 UUIDv4 作为 key。
- 内联内容： 对于具有特定样式的文本范围（例如粗体、斜体），如果它们是作为独立组件或通过特定结构渲染的，也应考虑为其提供 key。

代码示例：使用稳定 key 的块级编辑器

假设我们的编辑器内容是一个由 Block 对象组成的数组，每个 Block 都有一个唯一的 id。

// 定义编辑器中的块类型
interface EditorBlock {
  id: string; // 唯一的ID，用作React的key
  type: 'paragraph' | 'heading' | 'image';
  content: string; // 或更复杂的结构
  // ... 其他块级属性，例如内部状态
  isCollapsed?: boolean; // 示例：一个块的内部UI状态
}

// 模拟编辑器内容的数据模型
const initialBlocks: EditorBlock[] = [
  { id: 'block-1', type: 'heading', content: '欢迎来到我的编辑器' },
  { id: 'block-2', type: 'paragraph', content: '这是一个段落，可以进行编辑。', isCollapsed: false },
  { id: 'block-3', type: 'image', content: 'https://example.com/image.jpg' },
  { id: 'block-4', type: 'paragraph', content: '另一个段落，尝试进行撤销操作。' },
];

// 一个简单的撤销/重做历史管理
function useEditorHistory(initialState: EditorBlock[]) {
  const [history, setHistory] = React.useState<EditorBlock[][]>([initialState]);
  const [historyPointer, setHistoryPointer] = React.useState(0);

  const currentState = history[historyPointer];

  const pushState = React.useCallback((newState: EditorBlock[]) => {
    // 确保新的状态与当前状态不同，避免重复记录
    if (JSON.stringify(newState) === JSON.stringify(currentState)) {
      return;
    }
    const newHistory = history.slice(0, historyPointer + 1);
    newHistory.push(newState);
    setHistory(newHistory);
    setHistoryPointer(newHistory.length - 1);
  }, [history, historyPointer, currentState]);

  const undo = React.useCallback(() => {
    if (historyPointer > 0) {
      setHistoryPointer(prev => prev - 1);
    }
  }, [historyPointer]);

  const redo = React.useCallback(() => {
    if (historyPointer < history.length - 1) {
      setHistoryPointer(prev => prev + 1);
    }
  }, [historyPointer, history.length]);

  return { currentState, pushState, undo, redo, canUndo: historyPointer > 0, canRedo: historyPointer < history.length - 1 };
}

// 示例：一个可折叠的段落块组件
const ParagraphBlock: React.FC<{
  block: EditorBlock;
  onContentChange: (id: string, newContent: string) => void;
  onCollapseToggle: (id: string) => void;
}> = React.memo(({ block, onContentChange, onCollapseToggle }) => {
  const [isEditing, setIsEditing] = React.useState(false); // 内部瞬态UI状态
  const inputRef = React.useRef<HTMLDivElement>(null);

  React.useEffect(() => {
    if (isEditing && inputRef.current) {
      inputRef.current.focus();
    }
  }, [isEditing]);

  const handleInput = (e: React.FormEvent<HTMLDivElement>) => {
    onContentChange(block.id, e.currentTarget.innerText);
  };

  const toggleCollapse = () => {
    onCollapseToggle(block.id);
  };

  console.log(`ParagraphBlock ${block.id} (content: "${block.content.substring(0, 10)}...") re-rendered.`);

  return (
    <div style={{ border: '1px solid #ccc', padding: '10px', margin: '10px 0', backgroundColor: '#f9f9f9' }}>
      <div style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'center' }}>
        <h4 onClick={() => setIsEditing(!isEditing)} style={{ cursor: 'pointer', margin: 0 }}>
          段落 {block.id.slice(-4)} {isEditing ? '(编辑中)' : ''}
        </h4>
        <button onClick={toggleCollapse}>
          {block.isCollapsed ? '展开' : '折叠'}
        </button>
      </div>
      {!block.isCollapsed && (
        <div
          ref={inputRef}
          contentEditable={isEditing}
          onBlur={() => setIsEditing(false)}
          onInput={handleInput}
          suppressContentEditableWarning={true}
          style={{
            minHeight: '20px',
            border: isEditing ? '1px dashed blue' : 'none',
            padding: '5px',
            marginTop: '5px',
            backgroundColor: isEditing ? '#e6f7ff' : 'transparent',
          }}
          dangerouslySetInnerHTML={{ __html: block.content }} // 注意：这里使用了dangerouslySetInnerHTML，真实编辑器中会有更安全的处理
        />
      )}
      <p style={{ fontSize: '0.8em', color: '#888' }}>
        内部状态: isEditing={isEditing.toString()}, isCollapsed={block.isCollapsed?.toString()}
      </p>
    </div>
  );
});

// 主编辑器组件
const Editor: React.FC = () => {
  const { currentState: blocks, pushState, undo, redo, canUndo, canRedo } = useEditorHistory(initialBlocks);

  const handleBlockContentChange = React.useCallback((id: string, newContent: string) => {
    const nextBlocks = blocks.map(block =>
      block.id === id ? { ...block, content: newContent } : block
    );
    pushState(nextBlocks);
  }, [blocks, pushState]);

  const handleBlockCollapseToggle = React.useCallback((id: string) => {
    const nextBlocks = blocks.map(block =>
      block.id === id ? { ...block, isCollapsed: !block.isCollapsed } : block
    );
    pushState(nextBlocks);
  }, [blocks, pushState]);

  const addParagraphBlock = () => {
    const newBlock: EditorBlock = {
      id: `block-${Date.now()}`,
      type: 'paragraph',
      content: '这是一个新添加的段落。',
      isCollapsed: false
    };
    pushState([...blocks, newBlock]);
  };

  const removeBlock = (id: string) => {
    const nextBlocks = blocks.filter(block => block.id !== id);
    pushState(nextBlocks);
  };

  const moveBlockUp = (id: string) => {
    const index = blocks.findIndex(b => b.id === id);
    if (index > 0) {
      const newBlocks = [...blocks];
      const [blockToMove] = newBlocks.splice(index, 1);
      newBlocks.splice(index - 1, 0, blockToMove);
      pushState(newBlocks);
    }
  };

  const renderBlock = (block: EditorBlock) => {
    switch (block.type) {
      case 'paragraph':
        return (
          <div key={block.id} style={{ display: 'flex', alignItems: 'center' }}>
            <ParagraphBlock
              block={block}
              onContentChange={handleBlockContentChange}
              onCollapseToggle={handleBlockCollapseToggle}
            />
            <button onClick={() => removeBlock(block.id)} style={{ marginLeft: '10px' }}>删除</button>
            <button onClick={() => moveBlockUp(block.id)} style={{ marginLeft: '5px' }}>上移</button>
          </div>
        );
      case 'heading':
        return <h2 key={block.id}>{block.content}</h2>;
      case 'image':
        return <img key={block.id} src={block.content} alt="Editor Image" style={{ maxWidth: '100%', display: 'block', margin: '10px 0' }} />;
      default:
        return null;
    }
  };

  return (
    <div style={{ maxWidth: '800px', margin: '20px auto', fontFamily: 'Arial, sans-serif' }}>
      <h1>React 内容持久化编辑器示例</h1>
      <div style={{ marginBottom: '15px' }}>
        <button onClick={undo} disabled={!canUndo}>撤销</button>
        <button onClick={redo} disabled={!canRedo} style={{ marginLeft: '10px' }}>重做</button>
        <button onClick={addParagraphBlock} style={{ marginLeft: '10px' }}>添加段落</button>
      </div>
      <div style={{ border: '1px solid #ddd', padding: '20px', minHeight: '300px', backgroundColor: '#fff' }}>
        {blocks.map(renderBlock)}
      </div>
    </div>
  );
};

// 在App.tsx或index.tsx中渲染Editor组件
// ReactDOM.render(<Editor />, document.getElementById('root'));

在这个例子中：

每个 EditorBlock 都有一个唯一的 id，它被用作 React 列表渲染的 key。
ParagraphBlock 组件是一个 React.memo 组件，它内部维护了 isEditing 这一瞬态 UI 状态。
当你编辑 ParagraphBlock 的内容，或切换其 isCollapsed 状态时，pushState 会记录新的 blocks 数组。
当你点击“撤销”或“重做”时，useEditorHistory 会更新 blocks 数组，触发 Editor 组件重新渲染。
由于 ParagraphBlock 使用了 React.memo 且 block.id 保持不变（作为 key），React 会复用 ParagraphBlock 的 Fiber 节点。这意味着 isEditing 状态不会丢失，即使 block.content 或 block.isCollapsed 属性发生了变化，React 也只会更新这些属性，而不会重新挂载组件。
如果你添加、删除或移动块，key 的作用就会体现出来：React 能够高效地识别出哪些块是新增、删除或移动的，从而只对受影响的 DOM 节点进行操作，而不是重绘整个列表。

4.2. 外部化关键状态（Lifting State Up）

概念： 将组件内部的状态提升到其共同的父组件，或使用全局状态管理库（如 Redux, Zustand, Context API）进行管理。
对 Fiber 复用的影响：
- 编辑器的核心内容（如 blocks 数组、当前选区）几乎总是需要外部化。
- 当这些外部状态通过撤销/重做更新时，React 会从上到下重新渲染受影响的组件树。
- 如果组件接收的是外部状态作为 props，那么当这些 props 变化时，如果 key 和 type 匹配，React 仍然会复用 Fiber 节点，只是更新其 props，然后组件内部根据新 props 进行渲染。
- 这使得撤销/重做能够有效地作用于整个编辑器的数据模型，而无需组件自身知道撤销/重做的逻辑。
在编辑器中的应用：
- 编辑器内容数组、选区、光标位置、当前模式（编辑/预览）等都应由顶层编辑器组件或全局状态管理库维护。
- 像 useEditorHistory 这样的撤销/重做逻辑也应作用于这个外部化的状态。

4.3. 受控组件与非受控组件的选择

受控组件： 值由 React state 控制。每次输入都会更新 state，然后 state 更新触发组件重新渲染。
- 优点： 状态完全可预测，易于集成撤销/重做、验证和格式化。
- 在编辑器中： 大部分文本输入（如 contenteditable 区域的文本内容）都应作为受控组件来管理。
非受控组件： 值由 DOM 自身管理（如 input 的 defaultValue）。
- 优点： 简单，性能可能稍好（不每次都触发 React 渲染）。
- 缺点： 难以与撤销/重做集成，难以在外部直接修改其值。
- 在编辑器中： 应谨慎使用。如果需要保留内部状态，但又不希望每次输入都触发 React 渲染，可以结合 ref 和事件监听，只在 blur 或特定操作时同步值到 React state。然而，对于编辑器内容本身，受控模式通常是更健壮的选择。

4.4. 性能优化与避免不必要的渲染

即使 Fiber 节点被复用，不必要的子组件渲染仍然会浪费性能。

React.memo (函数组件) / shouldComponentUpdate (类组件):
- 概念： 允许组件在 props 未发生变化时跳过自身的重新渲染。
- 对 Fiber 复用的影响： 如果组件跳过了渲染，其 Fiber 节点会被直接从 current 树复制到 workInProgress 树，保持不变，从而进一步确保内部状态的持久性。
- 在编辑器中： 大多数展示型组件和内容块组件都应该使用 React.memo 进行包装，确保只有当它们的 props 实际发生变化时才重新渲染。
- 注意： React.memo 进行的是浅比较。如果 props 包含对象或数组，需要确保这些对象/数组在数据更新时是不可变的，或者提供自定义的比较函数。
useCallback / useMemo Hooks:
- 概念： 用于缓存函数和计算结果，避免在父组件重新渲染时创建新的函数实例或重新计算值，从而防止作为 props 传递给子组件时导致子组件不必要的重新渲染。
- 在编辑器中： 为传递给子组件的回调函数（如 onContentChange、onCollapseToggle）使用 useCallback，为复杂的计算结果使用 useMemo。

4.5. 特殊场景：Portals 与 `contenteditable`

React Portals:
- 概念： 允许将子节点渲染到存在于父组件 DOM 层次结构之外的 DOM 节点。
- 对 Fiber 复用的影响： Portal 内的组件拥有独立的 DOM 挂载点。这意味着它们可以相对独立地管理自己的生命周期和状态，不受父组件或其他兄弟组件的 DOM 结构变化的影响。
- 在编辑器中的应用： 浮动工具栏、模态框、上下文菜单等，这些 UI 元素可能需要保持其内部状态（例如工具栏的激活状态、模态框的打开状态），即使编辑器主体内容被撤销/重做而发生大规模变化。通过 Portal，这些 UI 元素可以保持挂载，其 Fiber 节点和内部状态自然得到保留。
contenteditable 与 MutationObserver:
- 概念： 这是一个浏览器原生属性，可以将任何 HTML 元素变成可编辑的。浏览器会直接管理其中的文本和光标。
- 对 Fiber 复用的影响： 当使用 contenteditable 时，React 的角色从直接管理 DOM 文本内容转变为“观察”和“同步” DOM 状态与 React state。contenteditable 区域内部的文本编辑由浏览器原生处理，光标和选区自然得到保持。
- 在编辑器中的应用： Draft.js、Lexical 等现代富文本编辑器框架都大量依赖 contenteditable。它们通常会结合 MutationObserver 来监听 contenteditable 元素的 DOM 变化，然后将这些变化解析并同步回 React 的数据模型。这种方式有效地将文本内容的“持久化”委托给了浏览器。
- 挑战： 同步 contenteditable 的 DOM 状态与 React 的虚拟 DOM 状态是复杂的，需要仔细处理光标、选区、输入法等问题，以避免两者发生冲突。

4.6. 高级 Fiber 内部机制：`alternate` 与 `diff` 算法

理解 Fiber 内部的 diff 算法如何工作，有助于我们更好地设计组件。

current 和 workInProgress 树： React 维护两棵 Fiber 树。current 树代表当前屏幕上渲染的内容，workInProgress 树是在后台构建的下一帧内容。
节点复用条件： 在 workInProgress 树的构建过程中，React 会尝试从 current 树中复用 Fiber 节点。复用成功的关键条件是：
1. key 匹配： 在兄弟节点中，key 必须相同。
2. type 匹配： 元素的 type 必须相同（例如，都是 div，或者都是 MyComponent）。
复用过程： 如果 key 和 type 都匹配，React 会将 current 树中的 Fiber 节点复制到 workInProgress 树，并更新其 props 和 state。这个过程就是我们希望达到的“Fiber 节点复用”。
不复用： 如果 key 或 type 不匹配，React 会销毁旧的 current Fiber 节点（及其子树），并创建一个全新的 workInProgress Fiber 节点。

表格：Fiber 节点复用决策

`key` 匹配？	`type` 匹配？	React 行为	结果（对内容持久化）
是	是	复用 Fiber 节点，更新 props/state	保持内部状态，性能最佳
是	否	销毁旧 Fiber，创建新 Fiber	内部状态丢失，DOM 节点被替换
否	(不重要)	销毁旧 Fiber，创建新 Fiber（或移动现有 DOM）	内部状态丢失，DOM 节点可能被替换或移动
没有 `key`	是	按索引比较，可能销毁旧 Fiber，创建新 Fiber	内部状态可能丢失，性能较差，易出错

因此，核心策略始终是：确保编辑器中的每个可独立维护状态的内容块都有一个稳定且唯一的 key，并且尽量避免在撤销/重做时改变其 type。

5. 实践中的考量与进阶技巧

5.1. 焦点与选区的恢复

撤销/重做后保持光标位置和选区是用户体验的重中之重。

存储： 在每次记录快照时，除了内容数据，还需要存储当前的光标位置（selectionStart / selectionEnd 或更复杂的 Range 对象）。
恢复： 在撤销/重做后，根据存储的位置，使用 Range 和 Selection API (如 document.createRange(), window.getSelection().addRange()) 重新设置光标和选区。这通常需要在 useEffect 中执行，确保 DOM 已经更新。
库支持： 许多富文本编辑器库（如 Lexical、Slate.js）内置了对选区序列化和反序列化的支持。

5.2. 滚动位置的保持

存储： 记录滚动容器的 scrollTop 和 scrollLeft。
恢复： 在撤销/重做后，将存储的值重新设置给滚动容器。同样，这应在 DOM 更新后进行。
智能滚动： 也可以在撤销/重做后，将焦点所在的元素 scrollIntoView()，确保用户能看到他们正在编辑的部分。

5.3. 动态组件类型与通用 Wrapper

如果编辑器块的类型可以动态改变（例如，一个段落可以变成标题），这将导致 type 不匹配，从而强制 React 销毁并重新创建 Fiber 节点。

解决方案：

外部化所有关键内部状态： 确保所有重要的瞬态 UI 状态都被提升到父组件或全局状态管理中，这样即使组件重新挂载，状态也可以被父组件重新注入。
通用 Wrapper 组件： 使用一个通用的 Wrapper 组件，该组件本身保持稳定（key 和 type 稳定），然后根据数据模型中的 type 属性，在内部条件性地渲染不同的子组件。

// Example: GenericBlockWrapper.tsx
const GenericBlockWrapper: React.FC<{ block: EditorBlock; ...otherProps }> = React.memo(({ block, ...otherProps }) => {
  // 这里的key是block.id，确保了Wrapper的Fiber节点稳定
  // Wrapper本身的type也是稳定的
  switch (block.type) {
    case 'paragraph':
      return <ParagraphBlock block={block} {...otherProps} />;
    case 'heading':
      return <HeadingBlock block={block} {...otherProps} />;
    case 'image':
      return <ImageBlock block={block} {...otherProps} />;
    default:
      return null;
  }
});

// 在Editor组件中渲染时
// {blocks.map(block => <GenericBlockWrapper key={block.id} block={block} ... />)}

通过这种方式，GenericBlockWrapper 的 Fiber 节点保持不变，只有其内部的子组件会因 block.type 的变化而被替换。如果子组件的内部状态不重要，或者已经被外部化，这是一种可接受的策略。

5.4. 不可变数据结构

在管理编辑器状态时，强烈建议使用不可变数据结构。

优点：
- 简化 shouldComponentUpdate / React.memo： 浅比较足以判断对象或数组是否发生变化。
- 易于追踪变化： 每次修改都会产生一个新对象，便于快照记录和撤销/重做。
- 避免副作用： 确保组件不会意外修改共享状态。
工具： Immer.js 是一个非常强大的库，可以让你用可变的方式编写代码，但它会在底层自动生成不可变的数据结构。这极大地简化了复杂状态的更新。

5.5. 性能瓶颈与优化

尽管 Fiber 节点复用有助于性能，但大型编辑器仍然可能遇到性能瓶颈：

大量的 DOM 节点： 即使复用，如果文档非常长，DOM 节点数量仍然是性能杀手。
- 虚拟化 (Virtualization)： 只渲染视口内可见的组件。例如 react-window 或 react-virtualized 可以用于列表虚拟化。对于编辑器，这通常需要更复杂的块级虚拟化。
频繁的 pushState： 每次按键都记录一个快照可能导致历史记录过大。
- 去抖 (Debouncing) / 节流 (Throttling)： 对输入事件进行去抖，只在用户暂停输入或特定时间间隔后才记录快照。
- 合并操作： 将连续的打字操作合并为单个历史记录条目。
复杂的渲染逻辑： 避免在渲染函数中执行昂贵的计算。使用 useMemo 缓存计算结果。

6. 结语

在 React 大型编辑器应用中实现高效且状态保持的撤销/重做功能，核心在于深入理解 React 的协调机制和 Fiber 架构。通过为内容块提供稳定唯一的 key、外部化核心状态、合理利用 React.memo 和 useCallback 等优化手段，以及在必要时采用 contenteditable 和 Portals 等高级技术，我们可以最大限度地复用 Fiber 节点，从而在保证卓越性能的同时，提供流畅、无缝的用户体验。