ResizeObserver 为什么会循环触发：前端表格自适应列宽的防抖与断点

订单列表的容器从 1200px 缩到 900px 时，表格需要重新分配列宽；如果在 ResizeObserver 回调里立刻改表格宽度，浏览器可能再次通知同一个观察者，控制台随即出现 ResizeObserver loop completed with undelivered notifications。真正要处理的不是简单加一个全局防抖，而是把“测量”和“写入”拆开，并让相同的容器宽度不再重复计算。

先把问题缩小到 #orders-grid 的一轮布局

假设页面有一个订单表格，左侧筛选栏可以折叠，表格主体挂在 #orders-grid 上。表格根据容器宽度给“订单号、客户、金额、状态、操作”五列分配比例，操作列还设置了 min-width: 128px。

容易出问题的写法是：观察容器尺寸，算出新宽度，马上把结果写回容器或表格。写入会触发新的布局，新的布局又会让观察者收到通知。浏览器为了避免脚本一直占用布局阶段，会把未能及时交付的通知留到下一轮，并在控制台给出提示。

同步改宽为什么会再次触发观察回调

ResizeObserver 的回调参数里有一个 ResizeObserverEntry，其中的 contentRect.width 是本轮测量值。下面的代码把测量、计算、写入挤在一起：

const grid = document.querySelector('#orders-grid');
const table = grid.querySelector('table');

const observer = new ResizeObserver(([entry]) => {
  const width = entry.contentRect.width;
  const nextWidth = Math.max(width, 760);
  table.style.width = `${nextWidth}px`;
  grid.style.minHeight = `${table.offsetHeight + 1}px`;
});

observer.observe(grid);

这里有两个隐患。第一，table.style.width 可能改变表格的布局尺寸；第二，读取 offsetHeight 紧跟写入，会让浏览器在同一段脚本里强制重新计算布局。它们叠在一起时，问题常被误判成“ResizeObserver 不能用于表格”。实际上，观察本身没有问题，问题在于回调没有稳定点。

先记录三组值，别急着加延时

在本地复现时，可以暂时记录观察值、计算值和实际值：

console.table({
  observed: Math.round(entry.contentRect.width),
  planned: nextWidth,
  actual: Math.round(table.getBoundingClientRect().width)
});

如果三组值在几十毫秒内来回变化，通常是写入引起的布局反馈；如果观察值只变化两次，且最终实际宽度稳定，可能只是窗口拖动期间的正常通知，不必把它当成故障。

三种方案怎么选：同步写入、定时防抖还是按帧合并

表格自适应列宽常见有三种做法。同步写入最短，但最容易把布局反馈带回当前观察周期；传统 setTimeout 防抖能降低频率，却不一定和浏览器绘制节奏对齐；requestAnimationFrame 则适合把一帧里的多次尺寸变化合成一次写入。

选择规则很简单：如果写入值会改变观察对象的尺寸，优先按帧合并；如果只是更新一个不参与布局的状态文本，同步写入也可以。不要用防抖掩盖“每次计算结果都不同”的问题。

用 requestAnimationFrame 合并写入，再用断点缓存止住抖动

下面的实现把回调当成测量入口，只保存最新宽度；真正的列宽写入放到下一帧，并且只有跨过断点才重算。

const grid = document.querySelector('#orders-grid');
const table = grid.querySelector('table');
let frameId = 0;
let lastBucket = '';

function getBucket(width) {
  if (width  {
  const width = entry.contentRect.width;
  cancelAnimationFrame(frameId);
  frameId = requestAnimationFrame(() => applyColumns(width));
});

observer.observe(grid);

这个版本有三个稳定点：一帧内只保留最后一次测量；同一个宽度断点不会反复写 CSS；列宽通过自定义属性交给表格样式，而不是在每次回调里改多个单元格的内联宽度。

CSS 里保留最小可用宽度

#orders-grid {
  min-width: 0;
  overflow-x: auto;
}

#orders-grid table {
  width: 100%;
  min-width: 760px;
  table-layout: fixed;
}

#orders-grid table[data-layout="narrow"] {
  --action-width: 128px;
}

#orders-grid table[data-layout="wide"] {
  --action-width: 160px;
}

容器窄于 760px 时，让表格保持最小宽度并出现水平滚动，通常比把五列压成不可读的小字更可靠。这里的 760 不是通用标准，而是根据这张订单表的字段长度、操作按钮和中文字号测出来的项目约束；换一张表，应重新取值。

哪些情况下不适合继续观察尺寸

如果表格只需要在窗口变化时调整一次，可以直接监听外层布局状态或使用 CSS 容器查询，不必让 JavaScript 长期观察。只有当列宽计算依赖真实内容、需要同步第三方组件或要在布局变化后做额外测量时，才值得保留观察者。

组件卸载时也要调用 disconnect()，并取消尚未执行的动画帧，否则切换路由后，旧表格仍可能被回调引用：

function dispose() {
  observer.disconnect();
  cancelAnimationFrame(frameId);
}

另一个常见坑是把 getBoundingClientRect() 放进多层循环。先批量读，再批量写；列宽计算如果超过一帧预算，应该减少测量次数，而不是继续增加延迟。

上线前的检查清单

• 拖动浏览器窗口，确认 narrow、middle、wide 只在跨断点时切换。
• 打开控制台，确认观察值稳定后不再持续打印，且没有未交付通知提示反复出现。
• 折叠筛选栏、切换分页、销毁组件，再次打开页面，确认旧观察者已经断开。
• 用长订单号、空状态和多行客户名测试，确保最小宽度与水平滚动仍然可用。

常见问题

ResizeObserver 的回调里能不能直接改 class？

可以，但要确认这个 class 不会让被观察元素尺寸持续变化。更稳妥的做法是先比较断点，再在下一帧只切换一次状态。

加 setTimeout 以后提示消失，是不是已经修好？

不一定。提示消失可能只是把反馈推迟了。仍应检查测量值和写入值是否能收敛，并确认组件销毁后没有遗留观察者。

表格一定要用 ResizeObserver 吗？

不一定。如果 CSS 容器查询已经能完成列显示和换行，优先使用 CSS；涉及内容测量、第三方表格 API 或需要读取实际尺寸时，再用观察者补充。

把“重复通知”变成可解释的布局状态

ResizeObserver 适合做测量，不适合在每次通知里无条件重写布局。对订单表格这类组件，按帧合并、断点缓存、最小宽度和销毁清理缺一不可。把这四个边界写进实现后，控制台提示不再是靠延时碰运气消失，列宽变化也更容易复查。