回流和重绘 | 流年石刻

好的，这是一个非常核心的前端性能问题。我们从第一性原理出发，一步步拆解，彻底讲明白回流（Reflow）与重绘（Repaint），以及 React 是如何通过其 Diff 算法巧妙地管理这个过程的。

浏览器的渲染过程：一切的起点

要理解回流和重绘，首先必须明白浏览器是如何将代码变成我们看到的网页画面的。这个过程可以简化为以下几个关键步骤，我们可以把它想象成盖房子：

解析 HTML 生成 DOM 树 (The Blueprint)：浏览器接收到 HTML 代码，像阅读建筑蓝图一样，解析它并构建一个“文档对象模型”（DOM）。这棵树描述了页面的结构——哪里是墙（div），哪里是窗（img），哪里是门（a）。
解析 CSS 生成 CSSOM 树 (The Style Guide)：同时，浏览器解析所有的 CSS（外部、内部、行内样式），构建一个“CSS 对象模型”（CSSOM）。这本样式指南详细说明了每个元素的视觉属性——墙要刷成白色（color），窗户要多宽（width），门要有阴影（box-shadow）。
合并 DOM 和 CSSOM 生成渲染树 (The Render Tree)：浏览器将 DOM 树和 CSSOM 树结合起来，生成一棵“渲染树”（Render Tree）。这棵树只包含需要显示在页面上的节点以及它们的样式信息。例如，display: none 的元素就不会出现在渲染树里，因为它虽然在结构蓝图（DOM）里，但最终是不需要“盖”出来的。
布局 (Layout / Reflow)：有了渲染树，浏览器就知道要显示哪些元素以及它们的样式了。接下来就是 布局（Layout） 阶段，也称为 回流（Reflow）。在这一步，浏览器需要计算出每个元素在屏幕上确切的尺寸、位置和几何信息。就像施工队拿着最终的施工图，在工地上精确测量每个房间的长宽高、门窗的位置。这是一个从根节点开始的、递归的过程，任何一个微小的变动都可能影响到它的子元素，甚至是后续的兄弟元素。
绘制 (Painting / Repaint)：布局确定后，浏览器终于可以开始 绘制（Painting） 了，也称为 重绘（Repaint）。在这一步，浏览器将每个元素根据其计算好的几何信息和样式（颜色、背景、边框等）转换成屏幕上的实际像素。就像油漆工开始给测量好的墙壁刷上颜色。
合成 (Compositing)：现代浏览器为了优化性能，会把页面的某些部分（比如频繁变化的动画）提升到一个独立的“图层”（Layer）上。最后一步就是将这些图层按照正确的顺序合并、显示在屏幕上。

理解了这个过程，回流和重绘的定义就清晰了。

什么是回流（Reflow）和重绘（Repaint）？

回流 (Reflow)

回流的本质是重新计算元素的几何属性。当渲染树中某个部分的尺寸、结构或位置发生改变，浏览器需要从该节点开始，递归地重新计算其所有子孙节点以及可能受影响的兄弟节点的几何信息。

重绘 (Repaint)

重绘的本质是重新将元素绘制成像素。当一个元素的视觉表现发生变化（例如颜色、背景），但其布局没有改变时，浏览器只需重新绘制这个元素的外观，而无需重新计算其几何位置。

关键关系：

回流必将导致重绘：你改变了房间的大小（回流），那么你肯定需要重新粉刷墙壁（重绘）。
重绘不一定会导致回流：你只是给墙换个颜色（重绘），房间的尺寸和结构并不需要改变（无回流）。

因此，回流的性能开销远大于重绘。 它是一个阻塞性的操作，发生在浏览器的主线程上。频繁的回流会导致页面卡顿，严重影响用户体验。

实际场景分析

让我们看一些会触发回流和重绘的实际操作：

触发回流（高成本）的操作：

添加或删除可见的 DOM 元素：在页面上增加或移除一个 <div>。
元素尺寸改变：修改 width, height, padding, margin, border 等。
内容改变：文本数量改变或图片大小改变，导致元素尺寸变化。
浏览器窗口尺寸改变：resize 事件。
获取布局信息：这是最隐蔽也最危险的一种。当你用 JavaScript 获取像 offsetWidth, offsetHeight, scrollTop, clientTop 或 getComputedStyle() 这些需要即时、精确布局信息的属性时，浏览器为了给你一个准确的值，必须 立即执行一次回流，以确保所有之前的样式变更都已生效。

一个糟糕的例子（强制同步布局）：

JavaScript

const elements = document.querySelectorAll('.box');

// 性能极差！
elements.forEach(el => {
  // 每次循环都会强制浏览器回流，以获取准确的 offsetWidth
  const width = el.offsetWidth; 
  // 然后又进行一次写操作，可能再次导致回流
  el.style.width = (width * 1.2) + 'px'; 
});

在这个例子中，每次循环都执行了“读（offsetWidth）”然后“写（style.width）”的操作。浏览器为了保证 offsetWidth 的准确性，会强制清空队列中的待处理样式变更，并立即执行一次回流。如果有 100 个元素，就会导致 100 次回流。

触发重绘（较低成本）的操作：

改变 color
改变 background-color
改变 visibility
改变 outline
改变 box-shadow

性能优化思路：

优化的核心思想是减少回流和重绘的次数和范围。例如，通过 class 切换来批量修改样式，或者使用 DocumentFragment 在内存中构建好 DOM 子树再一次性插入，都能将多次回流合并为一次。

React 的 Diff 算法及其与回流/重绘的关系

传统的前端开发直接操作真实 DOM，开发者一不小心就会写出上面那个性能极差的代码。React 的出现，很大程度上就是为了将开发者从这种繁琐且易错的 DOM 操作中解放出来。其核心武器就是 虚拟 DOM (Virtual DOM) 和 Diff 算法 (Reconciliation)。

什么是 React Diff 算法？

用 JavaScript 对象模拟 DOM：React 在内存中维护一个轻量级的 JavaScript 对象树，这就是虚拟 DOM。它描述了真实 DOM 的结构和状态。
更新流程：当组件的 state 或 props 改变时，React 会做以下事情：
- 根据新的 state 和 props 生成一棵新的虚拟 DOM 树。
- 将这棵新树与上一次渲染时生成的旧虚拟 DOM 树进行比较（这就是 Diff 过程）。
- 找出两棵树之间的最小差异。
- 将这些差异进行批量（Batched）的、一次性 的更新到真实 DOM 上。

Diff 算法的核心策略

为了高效地找出差异，React 的 Diff 算法基于几个非常务实的启发式策略：

同层比较 (Level-by-Level)：React 只会对同一层级的节点进行比较，不会跨层级移动节点。如果一个组件在树中的层级发生了变化，React 不会去寻找它，而是直接销毁旧的、创建新的。这大大简化了算法复杂度。
不同类型则销毁重建：如果新旧两个节点的元素类型不同（例如 <div> 变成了 <span>），React 会直接销毁旧的 DOM 节点及其所有子节点，然后创建一个全新的 DOM 节点。
相同类型则更新属性：如果新旧节点类型相同，React 会保留对应的真实 DOM 节点，只更新那些发生变化的属性（如 className, style）。
列表通过 key 识别：这是 Diff 算法中最重要的一点。在比较一个子元素列表时，如果没有 key，React 会逐个对比，效率很低。例如，在列表头部插入一个新元素，会导致所有后续元素被认为是“修改”了。但如果提供了稳定且唯一的 key，React 就能通过 key 准确地识别出哪些元素是新增的、哪些是删除的、哪些是移动了位置，从而执行最高效的 DOM 操作（插入、删除、移动），而不是全部重新渲染。

Diff 算法与回流/重绘的根本关系

React Diff 算法的根本目的，就是为了最大限度地减少对真实 DOM 的操作，从而将昂贵的回流和重绘降到最低。

它通过以下方式实现了这一目标：

抽象化 DOM 操作：你不再直接调用 document.createElement, node.appendChild 等命令式 API。你只是声明式地描述你想要的 UI 状态，React 负责找出最高效的路径去实现它。
批量更新 (Batching)：这是最关键的一点。在一个事件循环（Event Loop Tick）中，所有由 setState 引发的状态变更，React 会将它们收集起来。Diff 算法计算出所有需要进行的 DOM 更改后，不会立即执行，而是将这些更改缓存起来，最后一次性地、批量地应用到真实 DOM 上。

场景对比：
- 无 React：el.style.width = '100px'; el.style.height = '100px'; el.style.margin = '10px'; —— 可能触发 3 次独立的回流。
- 用 React：你通过 setState 改变了这些值。React 在内存中计算出差异后，最终可能只执行类似 el.style.cssText = 'width:100px; height:100px; margin:10px;' 的一次性操作，将多次回流合并为一次。

最小化操作范围：通过 Diff 算法，特别是利用 key，React 能够精确地知道只需要移动一个 DOM 节点，而不是删除所有节点再重新创建。移动操作通常比删除和创建的组合开销小得多，因为它只涉及一次回流，且范围可控。

结论与最佳选择

回流和重绘是浏览器渲染过程中不可避免的环节，但它们是性能的主要瓶颈，尤其是回流。

React 通过引入虚拟 DOM 和 Diff 算法，充当了一个“智能中间层”。它像一个经验丰富的项目经理，代替我们这些开发者去和“施工队”（浏览器渲染引擎）沟通。我们只需要告诉经理我们最终想要什么样的房子（声明式 UI），经理会自己计算出最省钱、最省时（性能最高）的施工方案（最小化的 DOM 操作），然后把一张整合好的指令单（批量更新）交给施工队，让他们一次性搞定。

这种机制将开发者从复杂、易错的底层 DOM 操作中解放出来，让我们能更专注于业务逻辑，同时在绝大多数情况下保证了应用的性能。

因此，在构建复杂的、数据驱动的 Web 应用时，使用像 React 这样的现代框架是当前最优的选择。它不仅提升了开发效率和代码可维护性，其核心的 Diff 和批量更新机制，就是为了从根本上解决手动操作 DOM 容易引发的性能问题（即过多的回流与重绘）而设计的。

一个糟糕的例子（强制同步布局）解决方案

问题的核心：在循环中交替进行 DOM 的“读”操作（el.offsetWidth）和“写”操作（el.style.width = ...），这会频繁触发“强制同步布局”（Forced Synchronous Layout），导致性能雪崩。

每一次循环，浏览器都不得不为了给你一个精确的 offsetWidth 值而立即执行一次回流，清空它本可以稍后批量处理的“写操作”队列。

要解决这个问题，核心原则就是：分离读写，批量处理。

下面提供几种由浅入深的解决方案，其中方案二是通常情况下的最佳实践。

方案一：最直接的修复 - 分离读写循环

这是最容易理解的修改方式，直接将读和写操作分到两个独立的循环中。

修改后代码：

JavaScript

const elements = document.querySelectorAll('.box');
const widths = [];

// 1. 批量读取 (Read)
// 在这个循环中，我们只进行读操作。
elements.forEach(el => {
  widths.push(el.offsetWidth);
});

// 2. 批量写入 (Write)
// 在这个循环中，我们只进行写操作。
elements.forEach((el, index) => {
  el.style.width = (widths[index] * 1.2) + 'px';
});

为什么这样能行？

第一个循环（读）：我们先把所有盒子的宽度一次性全部读出来，存入一个数组。在这个过程中，由于没有写操作穿插其中，浏览器通常只需要在循环开始前计算一次布局即可，不会在每次 offsetWidth 调用时都触发回流。
第二个循环（写）：我们遍历元素，只进行赋值（写操作）。浏览器很聪明，它会把这些样式变更“暂存”起来，并不会每改一个 style.width 就立刻回流一次。它会等到当前 JavaScript 任务结束后，将所有的变更合并，进行一次总的回流和重绘来更新画面。

通过这种简单的分离，我们就将潜在的 N次回流优化成了最多 1 次回流。

方案二：更推荐的实践 - 使用 CSS 类

在大多数情况下，直接用 JavaScript 操作行内样式（el.style）并不是最佳选择。更好的做法是将样式逻辑封装在 CSS 中，JavaScript 只负责切换状态。

1. 定义好你的 CSS 状态

CSS

/* 基础样式 */
.box {
  width: 100px; /* 假设一个初始宽度 */
  transition: width 0.3s ease; /* 加上过渡会更平滑 */
}

/* 放大后的样式 */
.box-enlarged {
  width: 120px; /* 100px * 1.2 */
}

如果初始宽度不固定，你可以使用 CSS 的 transform 或者 CSS 变量，这甚至可以完全避免回流。

使用 transform (性能最好)

transform 和 opacity 是两个特殊的属性，对它们的更改通常可以被浏览器优化，仅触发合成（Compositing），连重绘都可能跳过，性能开销最小。

CSS

.box-enlarged {
  /* scaleX(1.2) 表示只在水平方向放大到120% */
  transform: scaleX(1.2); 
  transform-origin: left; /* 让它从左边开始放大 */
}

2. JavaScript 只负责添加类

JavaScript

const elements = document.querySelectorAll('.box');

// JavaScript 的职责变得非常简单和清晰
elements.forEach(el => {
  el.classList.add('box-enlarged');
});

为什么这是更好的方案？

关注点分离 (Separation of Concerns)：样式（怎么变）由 CSS 管理，行为（何时变）由 JavaScript 控制。代码更清晰，更易于维护。
性能更优：浏览器对 class 变化的优化是顶级的。当你批量添加类名时，浏览器会非常高效地计算最终样式并应用，其内部的优化机制通常比我们手动分离读写循环要更强大。特别是使用 transform 时，性能提升是巨大的。
可维护性：未来需要修改放大的效果时，你只需要去改 CSS 文件，完全不用动 JavaScript 代码。

方案三：动画和高频更新的终极武器 - `requestAnimationFrame`

如果你的操作不是一次性的，而是需要持续进行（例如，实现一个平滑的动画），那么应该使用 requestAnimationFrame。它能确保你的 DOM 写操作在浏览器下一次绘制之前执行，避免丢帧和不必要的布局抖动。

对于你提出的这个一次性修改的场景，requestAnimationFrame 有点杀鸡用牛刀，但原理是相通的：将写操作集中到最佳时机处理。

示例代码：

JavaScript

const elements = document.querySelectorAll('.box');
const widths = [];

// 1. 还是先读取
elements.forEach(el => {
  widths.push(el.offsetWidth);
});

// 2. 在下一次绘制前，批量执行写入
requestAnimationFrame(() => {
  elements.forEach((el, index) => {
    el.style.width = (widths[index] * 1.2) + 'px';
  });
});

这本质上是方案一的“豪华版”，它将写操作放到了一个由浏览器控制的、最佳的执行时机里。

最佳选择

对于一次性、静态的样式变更，方案二（使用 CSS 类）是绝对的最佳选择。它兼顾了性能、可读性和可维护性。
如果由于某些原因必须动态计算并设置行内样式，方案一（分离读写循环） 是一个简单有效的修复方法。
对于动画或需要连续发生的样式变更，必须使用方案三 (requestAnimationFrame) 或纯 CSS 动画/过渡。

浏览器的渲染过程：一切的起点

解析 HTML 生成 DOM 树 (The Blueprint)：浏览器接收到 HTML 代码，像阅读建筑蓝图一样，解析它并构建一个“文档对象模型”（DOM）。这棵树描述了页面的结构——哪里是墙（div），哪里是窗（img），哪里是门（a）。
解析 CSS 生成 CSSOM 树 (The Style Guide)：同时，浏览器解析所有的 CSS（外部、内部、行内样式），构建一个“CSS 对象模型”（CSSOM）。这本样式指南详细说明了每个元素的视觉属性——墙要刷成白色（color），窗户要多宽（width），门要有阴影（box-shadow）。
合并 DOM 和 CSSOM 生成渲染树 (The Render Tree)：浏览器将 DOM 树和 CSSOM 树结合起来，生成一棵“渲染树”（Render Tree）。这棵树只包含需要显示在页面上的节点以及它们的样式信息。例如，display: none 的元素就不会出现在渲染树里，因为它虽然在结构蓝图（DOM）里，但最终是不需要“盖”出来的。
布局 (Layout / Reflow)：有了渲染树，浏览器就知道要显示哪些元素以及它们的样式了。接下来就是 布局（Layout） 阶段，也称为 回流（Reflow）。在这一步，浏览器需要计算出每个元素在屏幕上确切的尺寸、位置和几何信息。就像施工队拿着最终的施工图，在工地上精确测量每个房间的长宽高、门窗的位置。这是一个从根节点开始的、递归的过程，任何一个微小的变动都可能影响到它的子元素，甚至是后续的兄弟元素。
绘制 (Painting / Repaint)：布局确定后，浏览器终于可以开始 绘制（Painting） 了，也称为 重绘（Repaint）。在这一步，浏览器将每个元素根据其计算好的几何信息和样式（颜色、背景、边框等）转换成屏幕上的实际像素。就像油漆工开始给测量好的墙壁刷上颜色。
合成 (Compositing)：现代浏览器为了优化性能，会把页面的某些部分（比如频繁变化的动画）提升到一个独立的“图层”（Layer）上。最后一步就是将这些图层按照正确的顺序合并、显示在屏幕上。

理解了这个过程，回流和重绘的定义就清晰了。

什么是回流（Reflow）和重绘（Repaint）？

回流 (Reflow)

重绘 (Repaint)

关键关系：

回流必将导致重绘：你改变了房间的大小（回流），那么你肯定需要重新粉刷墙壁（重绘）。
重绘不一定会导致回流：你只是给墙换个颜色（重绘），房间的尺寸和结构并不需要改变（无回流）。

因此，回流的性能开销远大于重绘。 它是一个阻塞性的操作，发生在浏览器的主线程上。频繁的回流会导致页面卡顿，严重影响用户体验。

实际场景分析

让我们看一些会触发回流和重绘的实际操作：

触发回流（高成本）的操作：

添加或删除可见的 DOM 元素：在页面上增加或移除一个 <div>。
元素尺寸改变：修改 width, height, padding, margin, border 等。
内容改变：文本数量改变或图片大小改变，导致元素尺寸变化。
浏览器窗口尺寸改变：resize 事件。
获取布局信息：这是最隐蔽也最危险的一种。当你用 JavaScript 获取像 offsetWidth, offsetHeight, scrollTop, clientTop 或 getComputedStyle() 这些需要即时、精确布局信息的属性时，浏览器为了给你一个准确的值，必须 立即执行一次回流，以确保所有之前的样式变更都已生效。

一个糟糕的例子（强制同步布局）：

JavaScript

const elements = document.querySelectorAll('.box');

// 性能极差！
elements.forEach(el => {
  // 每次循环都会强制浏览器回流，以获取准确的 offsetWidth
  const width = el.offsetWidth; 
  // 然后又进行一次写操作，可能再次导致回流
  el.style.width = (width * 1.2) + 'px'; 
});

触发重绘（较低成本）的操作：

改变 color
改变 background-color
改变 visibility
改变 outline
改变 box-shadow

性能优化思路：

React 的 Diff 算法及其与回流/重绘的关系

什么是 React Diff 算法？

用 JavaScript 对象模拟 DOM：React 在内存中维护一个轻量级的 JavaScript 对象树，这就是虚拟 DOM。它描述了真实 DOM 的结构和状态。
更新流程：当组件的 state 或 props 改变时，React 会做以下事情：
- 根据新的 state 和 props 生成一棵新的虚拟 DOM 树。
- 将这棵新树与上一次渲染时生成的旧虚拟 DOM 树进行比较（这就是 Diff 过程）。
- 找出两棵树之间的最小差异。
- 将这些差异进行批量（Batched）的、一次性 的更新到真实 DOM 上。

Diff 算法的核心策略

为了高效地找出差异，React 的 Diff 算法基于几个非常务实的启发式策略：

同层比较 (Level-by-Level)：React 只会对同一层级的节点进行比较，不会跨层级移动节点。如果一个组件在树中的层级发生了变化，React 不会去寻找它，而是直接销毁旧的、创建新的。这大大简化了算法复杂度。
不同类型则销毁重建：如果新旧两个节点的元素类型不同（例如 <div> 变成了 <span>），React 会直接销毁旧的 DOM 节点及其所有子节点，然后创建一个全新的 DOM 节点。
相同类型则更新属性：如果新旧节点类型相同，React 会保留对应的真实 DOM 节点，只更新那些发生变化的属性（如 className, style）。
列表通过 key 识别：这是 Diff 算法中最重要的一点。在比较一个子元素列表时，如果没有 key，React 会逐个对比，效率很低。例如，在列表头部插入一个新元素，会导致所有后续元素被认为是“修改”了。但如果提供了稳定且唯一的 key，React 就能通过 key 准确地识别出哪些元素是新增的、哪些是删除的、哪些是移动了位置，从而执行最高效的 DOM 操作（插入、删除、移动），而不是全部重新渲染。

Diff 算法与回流/重绘的根本关系

React Diff 算法的根本目的，就是为了最大限度地减少对真实 DOM 的操作，从而将昂贵的回流和重绘降到最低。

它通过以下方式实现了这一目标：

抽象化 DOM 操作：你不再直接调用 document.createElement, node.appendChild 等命令式 API。你只是声明式地描述你想要的 UI 状态，React 负责找出最高效的路径去实现它。
批量更新 (Batching)：这是最关键的一点。在一个事件循环（Event Loop Tick）中，所有由 setState 引发的状态变更，React 会将它们收集起来。Diff 算法计算出所有需要进行的 DOM 更改后，不会立即执行，而是将这些更改缓存起来，最后一次性地、批量地应用到真实 DOM 上。

场景对比：
- 无 React：el.style.width = '100px'; el.style.height = '100px'; el.style.margin = '10px'; —— 可能触发 3 次独立的回流。
- 用 React：你通过 setState 改变了这些值。React 在内存中计算出差异后，最终可能只执行类似 el.style.cssText = 'width:100px; height:100px; margin:10px;' 的一次性操作，将多次回流合并为一次。

最小化操作范围：通过 Diff 算法，特别是利用 key，React 能够精确地知道只需要移动一个 DOM 节点，而不是删除所有节点再重新创建。移动操作通常比删除和创建的组合开销小得多，因为它只涉及一次回流，且范围可控。

结论与最佳选择

回流和重绘是浏览器渲染过程中不可避免的环节，但它们是性能的主要瓶颈，尤其是回流。

这种机制将开发者从复杂、易错的底层 DOM 操作中解放出来，让我们能更专注于业务逻辑，同时在绝大多数情况下保证了应用的性能。

一个糟糕的例子（强制同步布局）解决方案

每一次循环，浏览器都不得不为了给你一个精确的 offsetWidth 值而立即执行一次回流，清空它本可以稍后批量处理的“写操作”队列。

要解决这个问题，核心原则就是：分离读写，批量处理。

下面提供几种由浅入深的解决方案，其中方案二是通常情况下的最佳实践。

方案一：最直接的修复 - 分离读写循环

这是最容易理解的修改方式，直接将读和写操作分到两个独立的循环中。

修改后代码：

JavaScript

const elements = document.querySelectorAll('.box');
const widths = [];

// 1. 批量读取 (Read)
// 在这个循环中，我们只进行读操作。
elements.forEach(el => {
  widths.push(el.offsetWidth);
});

// 2. 批量写入 (Write)
// 在这个循环中，我们只进行写操作。
elements.forEach((el, index) => {
  el.style.width = (widths[index] * 1.2) + 'px';
});

为什么这样能行？

第一个循环（读）：我们先把所有盒子的宽度一次性全部读出来，存入一个数组。在这个过程中，由于没有写操作穿插其中，浏览器通常只需要在循环开始前计算一次布局即可，不会在每次 offsetWidth 调用时都触发回流。
第二个循环（写）：我们遍历元素，只进行赋值（写操作）。浏览器很聪明，它会把这些样式变更“暂存”起来，并不会每改一个 style.width 就立刻回流一次。它会等到当前 JavaScript 任务结束后，将所有的变更合并，进行一次总的回流和重绘来更新画面。

通过这种简单的分离，我们就将潜在的 N次回流优化成了最多 1 次回流。

方案二：更推荐的实践 - 使用 CSS 类

在大多数情况下，直接用 JavaScript 操作行内样式（el.style）并不是最佳选择。更好的做法是将样式逻辑封装在 CSS 中，JavaScript 只负责切换状态。

1. 定义好你的 CSS 状态

CSS

/* 基础样式 */
.box {
  width: 100px; /* 假设一个初始宽度 */
  transition: width 0.3s ease; /* 加上过渡会更平滑 */
}

/* 放大后的样式 */
.box-enlarged {
  width: 120px; /* 100px * 1.2 */
}

如果初始宽度不固定，你可以使用 CSS 的 transform 或者 CSS 变量，这甚至可以完全避免回流。

使用 transform (性能最好)

transform 和 opacity 是两个特殊的属性，对它们的更改通常可以被浏览器优化，仅触发合成（Compositing），连重绘都可能跳过，性能开销最小。

CSS

.box-enlarged {
  /* scaleX(1.2) 表示只在水平方向放大到120% */
  transform: scaleX(1.2); 
  transform-origin: left; /* 让它从左边开始放大 */
}

2. JavaScript 只负责添加类

JavaScript

const elements = document.querySelectorAll('.box');

// JavaScript 的职责变得非常简单和清晰
elements.forEach(el => {
  el.classList.add('box-enlarged');
});

为什么这是更好的方案？

关注点分离 (Separation of Concerns)：样式（怎么变）由 CSS 管理，行为（何时变）由 JavaScript 控制。代码更清晰，更易于维护。
性能更优：浏览器对 class 变化的优化是顶级的。当你批量添加类名时，浏览器会非常高效地计算最终样式并应用，其内部的优化机制通常比我们手动分离读写循环要更强大。特别是使用 transform 时，性能提升是巨大的。
可维护性：未来需要修改放大的效果时，你只需要去改 CSS 文件，完全不用动 JavaScript 代码。

方案三：动画和高频更新的终极武器 - `requestAnimationFrame`

对于你提出的这个一次性修改的场景，requestAnimationFrame 有点杀鸡用牛刀，但原理是相通的：将写操作集中到最佳时机处理。

示例代码：

JavaScript

const elements = document.querySelectorAll('.box');
const widths = [];

// 1. 还是先读取
elements.forEach(el => {
  widths.push(el.offsetWidth);
});

// 2. 在下一次绘制前，批量执行写入
requestAnimationFrame(() => {
  elements.forEach((el, index) => {
    el.style.width = (widths[index] * 1.2) + 'px';
  });
});

这本质上是方案一的“豪华版”，它将写操作放到了一个由浏览器控制的、最佳的执行时机里。

最佳选择

对于一次性、静态的样式变更，方案二（使用 CSS 类）是绝对的最佳选择。它兼顾了性能、可读性和可维护性。
如果由于某些原因必须动态计算并设置行内样式，方案一（分离读写循环） 是一个简单有效的修复方法。
对于动画或需要连续发生的样式变更，必须使用方案三 (requestAnimationFrame) 或纯 CSS 动画/过渡。