ResizeObserver 监听卡片尺寸时如何避免无限回调：把布局写入移出通知阶段

卡片网格接入 ResizeObserver 后，最容易踩到的坑不是“监听不到”，而是回调里顺手改了宽高，下一轮布局又把同一个回调叫回来。页面看起来只是抖动几下，控制台却不断出现重复通知，复杂一点还会拖慢拖拽和窗口缩放。

把尺寸读取放在 ResizeObserver 回调里，把布局写入交给下一帧，并用 pending 标记合并同一帧内的多次通知，就能切断“通知—写入—再次通知”的反馈回路。

卡片越自适应，反馈回路越容易暴露

假设一个仪表盘卡片根据自身宽度决定列数：宽度小于 480px 时显示一列，超过 480px 时显示两列。最直观的写法是在观察回调中读取宽度，然后立即给卡片设置 gridTemplateColumns 或 height。

问题在于，样式写入会改变下一次布局。浏览器完成布局后再次通知 ResizeObserver，回调又写一次。即使最终值没有变化，复杂组件里的子元素也可能让通知链持续很久。

先把旧写法的通知链画清楚

下面这段代码故意保留了问题，便于在 DevTools Performance 中观察回调是否成串出现：

const panel = document.querySelector('.dashboard-card');

const observer = new ResizeObserver(([entry]) => {
  const width = entry.contentRect.width;
  panel.style.gridTemplateColumns = width 

这里的风险点只有一个：回调同时承担了“读尺寸”和“写布局”。当写入影响 panel 的最终尺寸时，通知就可能重新排队。

用 pending 和下一帧拆开读取与写入

更稳的结构是让 ResizeObserver 只记录最新尺寸。第一次通知到来时设置 pending，再用 requestAnimationFrame 安排一次 applyLayout；同一帧继续到来的通知只更新数据，不重复安排任务。

const panel = document.querySelector('.dashboard-card');
let latestWidth = 0;
let pending = false;

function applyLayout() {
  pending = false;
  const columns = latestWidth  {
  latestWidth = entry.contentRect.width;
  if (!pending) {
    pending = true;
    requestAnimationFrame(applyLayout);
  }
});

observer.observe(panel);

这段代码有两个收敛点。其一，pending 让同一帧内的多次测量共享一个写入任务；其二，applyLayout 先比较目标值，值没变就不触碰样式。布局写入不再发生在 ResizeObserver 的通知回调中，反馈链就被拆成了两段。

这个方案解决什么，不能解决什么

适合连续变化的拖拽和窗口缩放

拖拽面板时，尺寸可能在一个渲染周期内变化多次。只消费最后一个 latestWidth，可以减少无意义的中间布局，视觉上也更稳定。

不能替代真正的尺寸收敛条件

如果 applyLayout 每次都会把卡片高度改成一个新的值，哪怕写入已经移到下一帧，仍可能形成跨帧循环。此时要检查写入是否改变了被观察元素，必要时固定比较值、限制变化方向，或改为观察内部容器而不是外层容器。

不要用 disconnect 掩盖业务状态

切换路由、销毁组件时应调用 observer.disconnect() 清理观察关系；但它只负责生命周期，不负责修复布局逻辑。把 disconnect 放进回调里，反而容易漏掉后续重新挂载。

上线前用三组场景验收

• 窗口缩放：从 1280px 拖到 375px，再拖回去，检查列数是否只在断点附近变化，控制台没有持续回调。
• 内容变长：让卡片标题换成三行，确认布局仍能稳定停在同一个尺寸，不出现高度逐帧增长。
• 隐藏恢复：把卡片放进折叠面板，展开后确认最新尺寸能触发一次 applyLayout，组件卸载后没有残留观察。

如果 Performance 面板里仍看到长串 ResizeObserver 通知，先记录每次回调读取到的宽度和 applyLayout 写入的目标值。两者交替变化，说明收敛条件还不完整；两者不变但回调持续出现，则应继续排查子元素、字体加载或其他观察者。

相关问题

为什么 requestAnimationFrame 比 setTimeout 更适合这里？

requestAnimationFrame 会把写入安排到浏览器下一次绘制节奏中，和布局更新更容易对齐；setTimeout 只能提供时间延迟，不能表达“下一帧绘制前处理”。

pending 是否必须用布尔值？

不必须。只要能表达“已经安排过一次写入”，也可以保存帧句柄；布尔值更适合这个只需要合并任务、不需要取消任务的例子。

观察父元素还是观察卡片本身？

如果布局写入会改变卡片自身尺寸，优先观察不会被该写入直接改变的内部容器或父级；观察对象越接近写入目标，越需要严格的相等比较和收敛条件。

把读写边界留在代码结构里

ResizeObserver 并不危险，危险的是把测量、决策和布局写入塞进同一个回调。让回调只更新 latestWidth，用 pending 合并通知，再由 requestAnimationFrame 调用 applyLayout，代码的控制流会更容易观察，也更容易在真实的拖拽、缩放和卸载场景中验收。