ResizeObserver 无限循环怎么排查：用 requestAnimationFrame 合并布局写入

页面里的卡片宽度跟着容器自动适配时，ResizeObserver 非常实用：监听元素尺寸变化，按新拿到的尺寸调整内部内容。但如果回调里一边读取布局属性、一边立刻改写元素尺寸，控制台很可能抛出 ResizeObserver loop completed with undelivered notifications，拖动窗口缩放时页面还会出现无意义抖动。这个问题根本不是浏览器随机出bug，而是你这次布局写入的动作又触发了下一轮的尺寸通知。

要解决ResizeObserver无限循环，核心做法是把布局读取、计算和样式写入操作分开，通过requestAnimationFrame把所有布局写操作合并到下一帧执行，同时提前比对新旧目标值，没有实际改动就直接跳过写入逻辑，避免触发新一轮的尺寸监听回调。

ResizeObserver 无限循环通常从哪一行开始

先看一个大家很容易踩坑的实现。观察容器后，把内容宽度直接写回容器的 style，下一次布局计算又可能改变容器尺寸，于是观察器再次收到通知：

const panel = document.querySelector('.panel');

const observer = new ResizeObserver(([entry]) => {
  const width = entry.contentRect.width;
  panel.style.setProperty('--columns', width >= 900 ? 3 : 2);
});

observer.observe(panel);

这里的问题不在于设置 CSS 自定义属性本身，而在于回调没有判断新旧值，也没有安排写入时机。若 CSS 规则根据 --columns 改变了内边距、滚动条或子元素尺寸，观察对象就可能在同一轮布局中被再次改变。

排查时可以先加一个短期计数器：

let notifyCount = 0;
const observer = new ResizeObserver(([entry]) => {
  notifyCount += 1;
  console.log('resize notification', notifyCount, entry.contentRect.width);
});

如果一次拖动只改变了一次宽度，却在几十毫秒内连续打印很多次，先别急着调 debounce。要找的是“回调里的写入是否又影响了被观察尺寸”。

先画出一帧里的读取、写入和通知链

浏览器的布局问题很容易被一句“观察尺寸变化”带过。实际排查可以把一次回调拆成三类动作：

这张表的实用之处在于：如果“计算目标值”没有变化，第三步就应该跳过；如果必须写入，最好让它进入下一帧，而不是在通知回调中同步完成。

用 requestAnimationFrame 把布局写入收敛到下一帧

下面的写法保留观察回调的轻量特征：只读取宽度、计算列数、记录最后一次尺寸；真正的样式写入交给下一帧。pending 保证一帧里只排一个更新。

const panel = document.querySelector('.panel');
let pending = false;
let nextColumns = null;
let appliedColumns = panel.dataset.columns || '';

function applyColumns() {
  pending = false;
  if (nextColumns === null || nextColumns === appliedColumns) return;

  appliedColumns = nextColumns;
  panel.dataset.columns = appliedColumns;
  panel.style.setProperty('--columns', appliedColumns);
  nextColumns = null;
}

const observer = new ResizeObserver(([entry]) => {
  const width = entry.contentRect.width;
  nextColumns = width >= 900 ? '3' : '2';

  if (!pending) {
    pending = true;
    requestAnimationFrame(applyColumns);
  }
});

observer.observe(panel);

这里有两个关键检查点。第一，多个尺寸通知只会覆盖 nextColumns，不会创建一长串帧任务。第二，appliedColumns 让相同结果直接返回，避免“写入相同值—再次通知—再次写入”的循环。

如果调整尺寸时还需要更新子节点，尽量把 DOM 变更也放在 applyColumns 里完成，并让下一次通知只负责确认结果是否稳定。不要在观察器里同时读宽度、改高度、插入节点，再用一个 debounce 把所有动作包起来；那样只是把问题推迟，边界条件仍然存在。

检查点：如何确认循环真的被修好

修复后不要只看控制台没有红字。用下面的清单做一次小范围验证：

• 连续拖动窗口跨过 900px 阈值，确认列数从 2 到 3 只发生一次有效写入。
• 在 applyColumns 开头和观察回调中分别计数，确认一帧最多排队一次。
• 打开 Performance 面板录制拖动过程，查看是否出现长串 Layout 或持续增长的回调调用。
• 把容器宽度固定不动后再次触发父级刷新，确认相同列数不会重复改写 CSS。

如果页面确实需要根据尺寸重建大量节点，可以把“尺寸观察”和“内容重建”拆成两个阶段，并在重建前设置上限。例如单次更新最多处理一批卡片，下一批安排到后续帧，避免把修复后的单次写入变成新的长任务。

常见问题与误区：debounce、observe 和 CSS 变化

加 debounce 就不会循环了吗？

不一定。debounce 能减少回调频率，但如果最后一次回调仍然写入观察对象并再次改变尺寸，循环依然存在。先做新旧值比较，再决定是否需要节流或合并。

观察父容器还是观察内容元素？

观察谁取决于谁的尺寸是决策输入。若列数由容器宽度决定，就观察容器；不要为了方便观察每张卡片，再在回调里改卡片尺寸形成相互触发。

为什么只改 class 也可能触发通知？

class 可能改变 padding、border、字体或子元素布局。它虽然不是直接设置 width，但只要最终影响被观察元素的 content box，就会产生新的尺寸变化。

什么时候可以直接 unobserve？

组件卸载、节点从页面移除或观察任务只需执行一次时，应调用 unobserve 或 disconnect。这能避免旧节点和回调继续占用资源，但不能替代对布局写入循环的修复。

速查：ResizeObserver 回调的安全边界

把这类问题压缩成一句工程判断：回调负责读和算，下一帧负责写；写之前比较目标值，写之后检查尺寸是否收敛。只要能在 Performance 录制中看到通知、写入和下一帧更新形成有限链路，ResizeObserver 就从随机报错源变成了可验证的布局工具。