ResizeObserver 为什么会触发 loop completed with undelivered notifications：用 requestAnimationFrame 拆开布局反馈

页面里有一块可随内容变化的卡片，开发者工具却不断刷出 ResizeObserver loop completed with undelivered notifications。这通常不是浏览器“随机报错”，而是 ResizeObserver 回调修改了自己正在观察的尺寸，布局变化又把通知送回了同一个回调。把写入动作放到 requestAnimationFrame，再加上目标尺寸判断，才能让这条反馈链真正收敛。

ResizeObserver 适合观察尺寸，回调里不要无条件改回被观察尺寸；需要改布局时，把写入放进 requestAnimationFrame，并用期望尺寸或 CSS 约束阻断重复写入。

先把 ResizeObserver 的反馈链缩小

ResizeObserver 的通知发生在浏览器绘制前。回调读取尺寸本身通常没有问题，危险点在于回调又写入了同一个元素的宽高。下面的最小例子故意让宽度每次增加 10px，便于看清问题：

const box = document.querySelector(".box");

const observer = new ResizeObserver((entries) => {
  for (const entry of entries) {
    entry.target.style.width = `${entry.contentRect.width + 10}px`;
  }
});

observer.observe(box);

这里的 ResizeObserver 观察 box，回调里的 entry.target.style.width 又改变了 box。浏览器重新计算布局后，观察器得到新的尺寸，链路就回到了回调入口。浏览器会把无法在本轮绘制中交付的通知推迟，并报告 loop completed with undelivered notifications；它阻止的是用户代理被锁死，不是替应用修复无限增长。

把写入动作移到 requestAnimationFrame 的绘制边界

如果业务确实需要根据观察到的尺寸调整样式，先把回调变成“收集变化”，再在 requestAnimationFrame 中执行写入。下面的代码保留了三个真实节点：ResizeObserver、requestAnimationFrame 和 entry.target.style.width。

const pending = new Map();
let frameId = 0;

const observer = new ResizeObserver((entries) => {
  for (const entry of entries) {
    const nextWidth = Math.min(entry.contentRect.width + 10, 480);
    pending.set(entry.target, nextWidth);
  }

  if (frameId !== 0) return;
  frameId = requestAnimationFrame(() => {
    for (const [target, nextWidth] of pending) {
      if (target.getBoundingClientRect().width !== nextWidth) {
        target.style.width = `${nextWidth}px`;
      }
    }
    pending.clear();
    frameId = 0;
  });
});

示例的关键不是“永远套一层 RAF”。Math.min 给了宽度上限，pending 合并同一帧内的通知，比较当前宽度后才执行 entry.target.style.width。如果目标已经达到 480px，后续观察通知就不会继续制造新的尺寸变化。

回调里哪些写操作最容易把自己唤醒

这里别急着把所有逻辑都搬进 RAF。若回调只是把尺寸写入一个独立的状态容器，或者修改的是不会影响被观察元素的属性，就不一定存在环路。真正要找的是“回调写入 → 样式或布局变化 → 再次通知”这条边。

用可观测结果验收，而不是只看错误是否消失

1. 首次加载页面，记录控制台中该错误是否连续出现。
2. 拖动窗口或改变内容，让被观察元素产生至少一次真实尺寸变化。
3. 在回调中临时记录目标宽度，确认数值在上限内停止变化，而不是每帧递增。
4. 移除临时日志，再检查布局、滚动条和相邻元素是否出现闪烁或跳动。

如果错误只出现一次但布局最终稳定，可能是通知被推迟后的正常保护行为；如果它每帧出现，或元素仍在增长，就说明环路还在。此时优先检查回调中的 class、width、height 和 CSS 变量写入，不要只把控制台错误过滤掉。

相关问题

ResizeObserver 报错就代表代码完全失效吗？

不一定。浏览器可能已经得到稳定布局，但持续出现错误或伴随闪烁时，仍应修复触发环路的写入动作。

只使用 requestAnimationFrame 就够了吗？

不够。RAF 调整了执行时机，仍需要上限、期望值比较或其他终止条件，否则下一帧仍可能继续改变尺寸。

为什么改 class 也会触发 ResizeObserver？

class 可能改变 padding、边框、字体或布局规则。只要最终盒子尺寸发生变化，观察器就会收到通知。

总结：观察和写入之间要有边界

这类报错的排查重点不是浏览器版本，而是回调是否把观察到的尺寸无条件写回自身。保留明确的尺寸上限，合并同一帧通知，在 requestAnimationFrame 中做一次有条件的写入，再用缩放和内容变化复测，反馈链才会从“每帧循环”变成“变化一次、收敛一次”。