DOM 的暴君与 React 的外科手术：深度解析 diffProperties 与硬件级优化

各位同学，把手里的咖啡放一放，把那个正在疯狂点击“刷新”按钮的手指停下来。

今天我们不聊 useEffect 的依赖数组，也不聊那个让你深夜崩溃的闭包陷阱。今天我们要聊的是 React 最核心、最硬核，也是让浏览器“既爱又恨”的部分——DOM 操作的原子化写入与硬件级优化。

如果你觉得 React 只是简单地修改 div.style.top，那你对它的误解就像以为程序员都在写“Hello World”一样深。React 是个强迫症患者，它是个完美的外科医生，而 diffProperties 就是它手里的手术刀。

准备好了吗？让我们钻进 React 的源码里，看看它是如何把那些笨重的 DOM 操作，变成一场精密的硬件级舞蹈。

一、 DOM 是个难伺候的暴君

首先，我们要明确一个残酷的现实：DOM 是慢的。

为什么？因为浏览器不知道你在想什么。当你修改 element.style.left 时，浏览器会想：“哦，布局变了？那我得重新算一遍所有在这个元素下面的兄弟元素的位置。哎呀，兄弟元素下面的元素位置也变了？那我也得算。哎呀，算了，整个文档流都乱了，重排（Reflow）走起！”

重排是 CPU 的重活，是内存的搬运工。如果我们在每一帧都让 CPU 忙着搬砖，页面就会卡顿，就像一辆跑车在泥潭里起步。

React 的目标就是：尽量少地打扰这个暴君，或者，用最优雅的方式让他动起来。

原子化写入：一次写入，多次读取

在 React 中，Props 更新不是“啪”的一声，DOM 就变了。React 的更新流程是分阶段的：

渲染阶段：在内存中计算新的 DOM 结构。
提交阶段：将计算好的结果应用到真实的 DOM 节点上。

所谓的“原子化写入”，并不是说 React 把代码变成原子了，而是指在提交阶段，React 会收集所有的变更，然后一次性、批量地应用到 DOM 上。这就像你不想去银行存钱（修改 DOM），你不想去银行存 10 次，你攒够了 10 块钱，一次性存进去。银行柜台（浏览器）处理一次就完了。

那么，谁来决定哪些属性变了？谁负责把这些变更变成 DOM 的指令？这就是我们的主角——diffProperties。

二、源码解剖：diffProperties 是个什么鬼？

打开 react-dom 的源码，搜索 diffProperties。你会看到一个巨大的函数，里面充满了 switch 语句和对象映射。这看起来很丑陋，但这正是 React 高效的秘密武器。

diffProperties 的主要任务很简单：接收旧的属性（prevProps）和新的属性（nextProps），返回一个差异列表。

// 这是一个极度简化版的 diffProperties 逻辑（基于 React 18 源码逻辑）
function diffProperties(
  currentElement,
  type,
  lastProps,
  nextProps,
  rootContainerElement,
  parentNamespace
) {
  let updatePayload = null;
  let lastProps = lastProps || {};
  let nextProps = nextProps || {};

  // 1. 检查属性是否真的变了
  for (let propKey in nextProps) {
    if (nextProps[propKey] !== lastProps[propKey]) {
      // 如果变了，加入更新队列
      updatePayload = updatePayload || {};
      updatePayload[propKey] = nextProps[propKey];
    }
  }

  // 2. 检查是否删除了属性
  for (let propKey in lastProps) {
    if (!(propKey in nextProps)) {
      updatePayload = updatePayload || {};
      updatePayload[propKey] = undefined;
    }
  }

  return updatePayload;
}

看懂了吗？ 这段代码非常朴素。它遍历了所有的新旧属性，做了一个简单的 !== 比较。

但是，这里有个巨大的坑。直接比较值是不够的。

比如，style={{ top: 10 }} 和 style={{ top: 10 }}，值一样，React 不会做任何事，完美。但是，如果值变了，React 怎么告诉浏览器？

这就涉及到宿主属性的处理。不同的属性，对浏览器的副作用完全不同。

三、硬件级优化路径：布局 vs 合成

这是本文最核心的部分。React 不仅仅知道属性变了，它还知道这个属性变了，会导致浏览器是去重绘页面，还是去合成层，或者去触发昂贵的重排。

让我们看看 React 是如何区分对待这些属性的。在 updateDOMProperties 函数中，有一段非常精彩的逻辑。

1. 布局属性：CPU 的噩梦

当你在 CSS 中使用 top, left, width, height, margin, padding 等属性时，你实际上是在告诉浏览器：“改变我的布局流。”

这会强制浏览器重新计算页面中所有元素的位置。这是最昂贵的操作。

React 的策略： 如果检测到这些属性变更，React 会确保在提交阶段，仅针对该属性进行更新，而不是触发全局重排。虽然浏览器还是得重排，但 React 至少没有瞎折腾其他东西。

源码逻辑示例：

// 伪代码：处理 style 属性
function updateDOMProperties(node, lastProps, nextProps) {
  let styleUpdates = null;

  // 遍历所有 style 属性
  for (let propKey in nextProps) {
    let nextProp = nextProps[propKey];
    let lastProp = lastProps[propKey];

    // 如果 style 属性是数字（如 top: 10），React 会自动转成字符串 '10px'
    if (typeof nextProp === 'number' && typeof lastProp !== 'number') {
       // 这是一个典型的 React 优化细节
       // 它会自动处理单位，避免你在 JS 里写 '10px' 还要手动加单位
       updatePayload[propKey] = nextProp + 'px'; 
    } else if (nextProp !== lastProp) {
       updatePayload[propKey] = nextProp;
    }
  }

  // 关键点：React 会把 style 对象拆解成一个个单独的属性更新
  // 而不是直接调用 node.style.cssText = '...'
  if (styleUpdates) {
    for (let styleName in styleUpdates) {
      // 这里直接调用原生 API
      node.style[styleName] = styleUpdates[styleName];
    }
  }
}

为什么 node.style.cssText 是不好的？
如果你在循环里对同一个 DOM 节点执行 10 次操作，然后最后才写 node.style.cssText = ...，浏览器可能只会重排一次。但是，如果 React 在每一帧都去操作 DOM，它没法预知你后面还要加什么。

所以，React 采用的是“细粒度更新”：改一个属性，就调一次 API。虽然 API 调用次数多了，但是浏览器可以合并这些操作吗？不，浏览器通常不能合并同一帧内的多次样式修改，除非你用了 requestAnimationFrame 的批量处理。

但是，React 在 commit 阶段 做了更高级的优化：它收集了所有需要更新的节点，然后一次性批量处理。

2. 合成属性：GPU 的狂欢

现在，让我们来看看那些不需要重排的属性。transform: translate(10px, 10px)，opacity: 0.5，filter: blur(5px)。

这些属性不需要改变元素在文档流中的位置，它们只需要改变元素的视觉呈现。现代浏览器（Chrome, Firefox, Safari）会把这些元素提升到独立的 合成层。

React 的策略： 如果是这些属性，React 会非常开心。因为它知道这些操作是在 GPU 上进行的，不需要 CPU 去搬砖。React 会生成对应的 CSS 变更，并利用浏览器的硬件加速能力。

代码示例：对比两种写法的性能

// 场景：把一个 div 从 (0,0) 移动到 (100, 100)

// 写法 A：使用 top/left (React 默认优化路径)
// React 代码逻辑：
function moveDivA(element) {
  element.style.top = '100px';  // 触发重排
  element.style.left = '100px'; // 再次触发重排
}

// 写法 B：使用 transform (硬件加速)
// React 代码逻辑：
function moveDivB(element) {
  element.style.transform = 'translate(100px, 100px)'; // 仅触发合成
}

// React 的 diffProperties 会怎么选？
// 它会检查你的 CSS。如果你的 CSS 里写了 transform: translate3d(0,0,0)
// React 会优先使用 transform 属性进行更新。
// 这就是所谓的“硬件级优化路径”。

在 React 源码中，updateDOMProperties 函数里有一张巨大的表，记录了哪些属性是“布局属性”，哪些是“合成属性”。

// 简化的属性分类表
const Layout = new Set(['top', 'left', 'width', 'height', ...]);
const Composite = new Set(['transform', 'opacity', 'filter', ...]);

// 当 React 遍历 diffProperties 返回的更新列表时
// 它会根据这个分类表来决定更新的优先级或方式

四、事件委托：省下 1000 个监听器

除了样式属性，React 对宿主属性的另一个巨大优化是事件处理。

假设你有 1000 个按钮。如果你给每个按钮都绑一个 onClick，浏览器就要创建 1000 个事件监听器。这太浪费内存了，而且事件冒泡会像滚雪球一样慢。

React 的做法是：事件委托（Event Delegation）。

在 React 源码中，diffProperties 并不直接处理事件绑定。它处理的是“属性”。
当你写 <button onClick={handleClick}> 时，React 不会在真实 DOM 上创建 onclick 属性（除了极少数情况），而是创建一个 onclick 属性。

关键代码：

// React 在处理事件属性时
if (propKey.startsWith('on')) {
  const eventType = propKey.toLowerCase().substring(2);
  // React 会将这个事件注册到 root 节点上
  // 不是给每个按钮注册，是给根节点注册！
  registerEventHandler(rootNode, eventType, handleEvent);
}

原理：

React 在根节点（通常是 div#root）上挂载一个监听器。
当用户点击按钮时，浏览器把事件冒泡到根节点。
React 的合成事件系统拦截这个事件。
React 检查事件源，看是否匹配某个 Fiber 节点的处理函数。
执行对应的函数。

这就是硬件级优化在事件层面的体现：
减少了内存占用（CPU），减少了事件监听器的创建时间，并且利用了事件委托的机制，极大地减少了垃圾回收（GC）的压力。React 把 1000 个监听器变成了 1 个监听器，这不仅是代码优化，这是资源优化。

五、 className vs class：React 的强迫症

在 HTML 中，设置类名用 class。在 JavaScript 中，class 是保留关键字。所以 React 必须用 className。

在 diffProperties 中，React 会做这个转换：

// 如果用户写的是 class="foo bar"
// React 内部会把它映射到 DOM 属性
if (propKey === 'className') {
  // React 会调用 DOMPropertyOperations.setAttribute
  // 它会自动处理空格分隔的字符串，转换成 DOM 需要的格式
  DOMPropertyOperations.setValueForProperty(node, 'class', nextProp);
}

为什么这很重要？因为浏览器的 setAttribute 比直接操作 element.className 慢得多。React 的 diffProperties 会检测到 className，然后直接走捷径，调用 element.className = ...。

原子化写入在这里的体现：
React 不会在遍历 DOM 树的时候，看到 className 变了就立马去修改 DOM。它只是把 className 放进 updatePayload。只有当这个 Fiber 节点确定要被提交（commit）时，updateDOMProperties 才会被调用。

// commitWork 函数中的逻辑
function commitWork(fiber) {
  if (fiber.effectTag === Update) {
    const domNode = fiber.stateNode;
    // 获取之前 diffProperties 计算出来的 props 变更
    const newProps = fiber.memoizedProps; 

    // 真正的原子化写入发生在这里
    updateDOMProperties(domNode, fiber.alternate?.memoizedProps, newProps);
  }
}

注意那个 fiber.alternate。React 使用双缓冲技术。fiber.alternate 指向旧的 Fiber 树。这意味着在提交之前，React 实际上是在内存里对比了新旧两棵树，计算出了差异，然后一次性写入。

六、文本节点的处理：nodeValue vs textContent

处理 children 是 React 最头疼的事情之一，因为它可能是文本，可能是数组，可能是 JSX 元素。

但在 diffProperties 处理宿主属性时，如果发现是文本节点，React 会非常谨慎。

// 如果节点是文本节点
if (node.nodeType === Node.TEXT_NODE) {
  const textContent = nextProp; // nextProps 可能是字符串
  if (textContent !== node.nodeValue) {
    node.nodeValue = textContent;
  }
}

为什么不用 innerHTML？
React 从不使用 innerHTML 来更新子节点（除了极少数特殊场景）。为什么？因为 innerHTML 会销毁并重建整个子树。这意味着所有的事件监听器都会丢失，所有的状态都会重置。

React 的做法是：

如果是文本节点，只更新 nodeValue。
如果是子节点列表，React 会递归地调用 diffProperties 和 commitWork。

这种“增量更新”保证了 DOM 结构的稳定性，也保证了性能。

七、总结：React 的哲学

好了，我们绕了一大圈，从 diffProperties 到 updateDOMProperties，再到具体的 DOM API 调用。

React 属性更新的原子化写入，本质上是一种“延迟执行 + 批量处理 + 智能分类”的混合策略。

延迟执行：不修改 DOM，只修改内存中的 Fiber 树。
批量处理：在一个渲染周期内，收集所有的变更，最后一次性提交。
智能分类：diffProperties 负责识别哪些属性是昂贵的（布局），哪些是便宜的（合成）。它优先处理合成属性，尽量减少重排。

代码示例：一个完整的优化流程模拟

让我们模拟一下 React 在提交阶段是如何工作的。

// 1. 渲染阶段结束，React 计算出差异
// 假设有一个 div，它的 style 从 { top: 0 } 变成了 { top: 100, opacity: 0.5 }

// 2. 进入提交阶段
function commitRoot() {
  // 找到所有需要更新的 fiber 节点
  let firstEffect = root.firstEffect;

  while (firstEffect !== null) {
    // 3. 遍历 effect 列表
    if (firstEffect.effectTag & Update) {
      // 4. 获取 DOM 节点
      const domNode = firstEffect.stateNode;

      // 5. 获取新的 props
      const newProps = firstEffect.memoizedProps;

      // 6. 执行更新（原子化写入）
      // React 知道 top 是布局属性，opacity 是合成属性
      // 它会依次调用
      domNode.style.top = newProps.style.top; // 可能触发重排
      domNode.style.opacity = newProps.style.opacity; // 合成层更新

      // 注意：React 会尽量把这些操作放在同一个 JS 执行栈中
      // 这样浏览器的重排只会发生一次
    }

    nextEffect = firstEffect.nextEffect;
    firstEffect = nextEffect;
  }

  // 7. 提交完成，浏览器开始渲染下一帧
}

你看，这就是 React 的魔法。它把繁重的计算工作分散在渲染阶段，把昂贵的 DOM 操作集中在提交阶段，并且通过 diffProperties 这种精细的算法，尽量让浏览器只做它必须做的事。

最后，记住这句话：
React 不会替你写代码，但 React 会替你省下不必要的 CPU 周期。它通过 diffProperties 这种看似笨重实则精密的映射机制，把 JavaScript 的逻辑操作，转化成了浏览器最擅长的硬件指令。

这就是为什么 React 能跑得飞快。它不是在跟浏览器比速度，它是在帮浏览器偷懒。

好了，今天的讲座就到这里。现在，去检查一下你的代码，是不是还在用 innerHTML 更新列表？是不是还在用 style.top 做动画？如果是，React 会伤心的。

React 属性（Props）更新的原子化写入：源码解析 diffProperties 对特定宿主属性的硬件级优化路径

DOM 的暴君与 React 的外科手术：深度解析 diffProperties 与硬件级优化

一、 DOM 是个难伺候的暴君

原子化写入：一次写入，多次读取

二、源码解剖：diffProperties 是个什么鬼？

三、硬件级优化路径：布局 vs 合成

1. 布局属性：CPU 的噩梦

2. 合成属性：GPU 的狂欢

四、事件委托：省下 1000 个监听器

五、 className vs class：React 的强迫症

六、文本节点的处理：nodeValue vs textContent

七、总结：React 的哲学

发表回复取消回复

DOM 的暴君与 React 的外科手术：深度解析 diffProperties 与硬件级优化

一、 DOM 是个难伺候的暴君

原子化写入：一次写入，多次读取

二、 源码解剖：diffProperties 是个什么鬼？

三、 硬件级优化路径：布局 vs 合成

1. 布局属性：CPU 的噩梦

2. 合成属性：GPU 的狂欢

四、 事件委托：省下 1000 个监听器

五、 className vs class：React 的强迫症

六、 文本节点的处理：nodeValue vs textContent

七、 总结：React 的哲学

发表回复 取消回复

二、源码解剖：diffProperties 是个什么鬼？

三、硬件级优化路径：布局 vs 合成

四、事件委托：省下 1000 个监听器

六、文本节点的处理：nodeValue vs textContent

七、总结：React 的哲学

发表回复取消回复