前端批量更新表单时如何用 requestAnimationFrame 合并 DOM 写入：布局抖动的定位与修复

批量修改表单行时，页面卡顿常常不是循环本身太慢，而是循环里反复交替读取布局和写入样式。浏览器刚算完一行的尺寸，下一次写入又让旧布局失效，随后读取 offsetHeight 只好立刻触发新的布局。把读取集中到前面，再把写入交给 requestAnimationFrame，通常就能先消掉这类抖动。

先读完本帧需要的尺寸，再在一个 requestAnimationFrame 回调中集中写入；它能减少强制同步布局，但不能替代对 DOM 数量和样式复杂度的检查。

表单行越多，读写交错越容易放大布局成本

假设一个订单编辑页允许一次调整几十行商品数量。旧代码常把“算出当前高度”和“设置下一行宽度”写在同一个循环里。row.offsetHeight 是布局读取，row.style.height 是布局写入；两者交替出现时，浏览器无法等到自然渲染阶段再统一计算。

这里先别急着给循环加节流。先在 Chrome DevTools 的 Performance 面板录一段输入操作，展开主线程中的紫色 Layout 事件，再看调用栈是否回到批量更新函数。这个证据比凭感觉改成异步更可靠。

把 measureRows 和 scheduleRowWrites 拆成两段

下面的示例只处理一个任务：根据表单行的当前高度，集中更新行内提示区域。measureRows 只读布局，scheduleRowWrites 只负责写入；这两个名字也会出现在配图中，便于对照控制流。

const rows = [...document.querySelectorAll('.order-row')];

function measureRows(rows) {
  return rows.map((row) => ({
    row,
    height: row.offsetHeight
  }));
}

function scheduleRowWrites(measures) {
  requestAnimationFrame(() => {
    for (const { row, height } of measures) {
      row.style.setProperty('--row-height', `${height}px`);
    }
  });
}

function syncRowHints() {
  const measures = measureRows(rows);
  scheduleRowWrites(measures);
}

document.querySelector('#order-form').addEventListener('input', syncRowHints);

调用顺序是 syncRowHints → measureRows → scheduleRowWrites → requestAnimationFrame。测量结果以普通对象暂存，所以回调写入时不需要再次读取布局。这里的 --row-height 只是自定义属性；如果最终要改变 height、width、top 等几何属性，仍要观察整个页面的 Layout 成本。

这段改动解决了什么，又没有解决什么

改动的收益是把一轮操作里的布局读取和样式写入分开，避免“写入后马上读取”迫使浏览器同步补算布局。它不保证每帧都轻松：如果表单有数千个节点，单次样式更新仍然可能很重；如果事件持续触发，还需要保存待处理状态并在下一帧合并，而不是无条件排队大量回调。

输入事件也可能发生在浏览器后台标签页。requestAnimationFrame 回调会随浏览器的渲染节奏暂停或降频，因此它适合视觉更新，不适合承载必须准时执行的业务逻辑。业务数据应在事件处理阶段完成校验，视觉同步再交给帧回调。

用可见证据确认抖动确实减少

再次录制同样的输入操作，重点看三件事：主线程中是否还出现由脚本触发的连续 Layout；回调是否集中落在 requestAnimationFrame 附近；输入到下一次绘制之间是否出现明显长任务。不要只看一次录制结果，至少用少量行和较多行各测一遍，确认方案没有把问题从读写交错变成单次大更新。

如果仍有强制布局，继续沿调用栈检查其他代码是否在写入后访问了 getBoundingClientRect()、offsetWidth 或 offsetHeight。这类读取同样可能迫使浏览器提前完成样式计算和布局。

常见问题

把所有更新都放进 requestAnimationFrame 就一定更快吗？

不一定。它只负责把视觉写入安排到即将渲染的帧，真正的收益来自读写分离和减少不必要的布局；DOM 过大、选择器昂贵或单次更新过多时仍需单独优化。

为什么还要保留 measureRows，而不是在回调里读取？

回调里先读取再写入也能避免同一回调内部的交错，但提前集中读取更容易审查数据边界，也避免前置代码已经写过样式后在回调里触发强制布局。实际项目应结合调用栈验证。

这类性能修复的最小闭环是：找到读写交错的位置，拆出 measureRows，用 scheduleRowWrites 在 requestAnimationFrame 中批量写入，再用 Performance 录制确认 Layout 触发方式。证据不支持收益时，就回到 DOM 规模和其他布局读取继续排查。