前端组件尺寸变化怎样避免循环更新

前端组件尺寸变化会触发 ResizeObserver，但回调里如果又无条件修改被观察元素的宽度、高度或影响布局的状态，就可能形成“尺寸变化—回调—再次布局—尺寸变化”的反馈。最稳妥的处理方式是把观察和写入分开：先读取尺寸，再和上一次结果比较，确实变化时才写入；一次性测量则在达到目标后调用 unobserve() 或 disconnect()。

官方地址：https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver

这篇只讨论回调更新和循环限制，不把 ResizeObserver 当成“监听后可以随便改尺寸”的万能入口。浏览器会对循环依赖做限制，但限制的目标是避免用户代理被锁死，并不等于业务代码的反馈已经自动消失。

先把观察与写入分开

我在组件里遇到这类问题时，先把回调看成一个“尺寸输入口”，而不是状态修改器。entry.contentRect 或盒模型尺寸告诉我们发生了什么；是否更新状态、更新哪个 CSS 属性，则应该由比较条件决定。这样做的关键不是多加一个计数器，而是让同一个尺寸再次进入回调时没有新的写入动作。

最小配方：缓存尺寸并只写入真正的变化

下面的配方适合原生 DOM，也可以把 applySizeState 换成框架组件的状态更新函数。示例把宽高取整，避免小数抖动导致重复写入；如果业务确实关心小数，可以改成固定精度比较。

const panel = document.querySelector(".panel");
let lastSize = null;
let frameId = 0;

const observer = new ResizeObserver((entries) => {
  const entry = entries[0];
  const width = Math.round(entry.contentRect.width);
  const height = Math.round(entry.contentRect.height);

  // 尺寸没有跨过有效精度时，不再次写入组件状态。
  if (lastSize && lastSize.width === width && lastSize.height === height) {
    return;
  }
  lastSize = { width, height };

  // 合并同一帧内的更新，避免回调里连续触发布局写入。
  cancelAnimationFrame(frameId);
  frameId = requestAnimationFrame(() => {
    applySizeState({ width, height }); // 只写入派生状态，不直接改 panel 尺寸。
  });
});

observer.observe(panel); // 只观察真正需要响应的组件节点。

这段代码的边界有三层。第一层是数值比较，尺寸没变就直接返回；第二层是 requestAnimationFrame，把同一帧里的多次通知合并到一次写入；第三层是写入内容，applySizeState 只应更新不会再次改变 panel 宽高的派生状态，例如紧凑模式标记或内部展示密度。

如果必须改变布局，就要把“期望尺寸”也纳入比较，不能只根据本次回调的尺寸再加一个固定值。否则写入的新尺寸会成为下一次观察的新输入，回调就可能一直有事情可做。

哪些写入最容易制造循环

下面三类写入值得优先排查：

尤其要留意“看起来只是设置 class”的代码。class 本身不是问题，问题在于它是否改变了被观察元素的 content box、border box 或内部内容高度。调试时可以把写入点临时收敛到一个函数，记录旧值、目标值和是否真的变化，通常比在回调里到处加日志更容易找到反馈边。

用期望尺寸让改变布局也能收敛

有些组件确实需要在测量后调整宽度，例如把卡片切换到一个明确的布局档位。这时不要“当前宽度加 10 像素”这种无终点写法，而是先算出稳定的目标值，并记住它。只有当前尺寸还没有达到目标时才写入。

const expectedWidth = new WeakMap();
const boxObserver = new ResizeObserver((entries) => {
  requestAnimationFrame(() => {
    for (const entry of entries) {
      const box = entry.target;
      const currentWidth = Math.round(entry.contentRect.width);
      const targetWidth = chooseStableWidth(currentWidth);

      // 目标值未变化时不触碰布局，防止同一反馈边重复写入。
      if (expectedWidth.get(box) === targetWidth && currentWidth === targetWidth) {
        continue;
      }
      if (currentWidth === targetWidth) {
        expectedWidth.set(box, targetWidth); // 到达稳定点，只更新记录。
        continue;
      }

      expectedWidth.set(box, targetWidth);
      box.style.width = `${targetWidth}px`; // 写入一个可达到的固定目标。
    }
  });
});

boxObserver.observe(document.querySelector(".box")); // 绑定一个明确目标。

这里的 chooseStableWidth 必须是有界的：相同的输入应得到相同的目标，目标不能随着每次回调无限增长。若目标依赖多个组件的互相测量，还要进一步确认它们不会互相改写对方的尺寸；ResizeObserver 能延迟部分通知，却不会替业务设计一个稳定点。

一次性测量完成后及时停止观察

如果组件只需要第一次得到可用尺寸，例如初始化画布比例、计算一次弹层位置或完成首屏布局，就不要永久保留观察者。观察单个节点可以调用 unobserve(target)；观察者不再服务任何目标时，可以调用 disconnect()。

const target = document.querySelector(".measure-once");
const oneShotObserver = new ResizeObserver(([entry]) => {
  const width = Math.round(entry.contentRect.width);
  const height = Math.round(entry.contentRect.height);

  if (width 

生命周期也要一起处理。组件被卸载时要解除观察，避免闭包继续持有节点或状态；如果一个观察者管理多个目标，就在确认所有目标都不需要时再用 disconnect()。这一步不是为了“压住错误提示”，而是把观察范围和业务生命周期对齐。

按清单排查循环更新

• 观察对象是否就是被回调写入的节点，或者写入会间接改变它的盒模型。
• 回调是否先比较旧尺寸与新尺寸，而不是每次都 setState、改 style 或切 class。
• 小数尺寸是否需要取整、阈值或固定精度，避免微小变化来回切换。
• 布局写入是否有明确期望值，并且相同输入能得到同一个稳定目标。
• 一次性任务是否在成功后调用 unobserve()，组件销毁时是否调用 disconnect()。
• 是否把浏览器的 “ResizeObserver loop completed with undelivered notifications” 当成根因；它更像是反馈设计需要检查的信号。

我通常先只保留“读取尺寸—比较—记录”的部分，再逐个恢复状态更新、class 切换和样式写入。这样可以确认循环是观察本身造成的，还是某个写入让布局重新变化。官方文档也建议对无意形成的循环设置期望尺寸；如果业务确实需要在回调后调整布局，可以把写入放入下一帧，但仍需保证它最终会收敛。

几个容易混淆的问题

requestAnimationFrame 能彻底解决循环吗？ 不能。它只能把写入推迟到重绘之后；如果每一帧都把尺寸继续改大，反馈仍会持续。真正的条件是目标值有界，或回调在达到稳定值后不再写入。

只调用 disconnect 就够了吗？ 对一次性任务可以切断观察，但它不能修复持续观察场景中的无条件写入。持续观察仍需要比较、稳定目标或只更新不影响被观察盒模型的派生状态。

为什么我没有改宽高，却还是反复回调？ 内容换行、字体、padding、border、class 和父级布局都可能改变被观察盒模型。沿着“哪个写入改变了哪一个盒子”去追踪，比只搜 style.width 更完整。

归纳起来，避免 ResizeObserver 循环更新不是给回调加一个固定延迟，而是建立清晰的反馈边界：尺寸先进入比较，状态只在必要时写入，布局调整要有可达到的期望值，一次性任务在完成后主动停止观察。