CSS container query 如何配合 ResizeObserver：避免响应式组件重复计算

同一个统计卡片放进侧栏和主内容区后，最容易出现的不是样式写错，而是 JavaScript 也开始监听每一次尺寸变化，结果拖动窗口时反复测量、反复写回 DOM。更稳妥的分工是：CSS container query 负责“卡片在当前宽度下长什么样”，ResizeObserver 只负责“尺寸变化是否会影响需要计算的数据”，并把连续通知合并到下一帧。

先把“样式响应”和“数据响应”分开

container query 观察的是容器的可用内联尺寸，适合控制网格列数、标题截断和操作按钮是否换行。它不会替你计算图表刻度，也不会通知业务代码“现在是窄卡片”。这些属于两条不同的链路。组件可以先让 CSS 完成布局，再用 ResizeObserver 读取最终的 contentRect.width，只在宽度跨过业务阈值时刷新统计数据。

下面的卡片只依赖自身宽度，而不是依赖页面某个固定断点：

.metric-card {
  container-type: inline-size;
  container-name: metric-card;
}

.metric-card__body {
  display: grid;
  grid-template-columns: 1fr;
  gap: 12px;
}

@container metric-card (min-width: 420px) {
  .metric-card__body {
    grid-template-columns: 1fr 1fr;
  }
}

ResizeObserver 只监听真正影响计算的尺寸

观察器回调可能在一次布局变化后收到多条记录，所以回调里不要直接调用昂贵的 measureAndRender。先取出宽度，只有业务分段发生变化时才标记待处理状态。这里的分段不是 CSS 的全部断点，而是数据计算确实需要的边界，例如宽卡片展示 7 天 sparkline，窄卡片只展示 3 天。

const card = document.querySelector('.metric-card');
let lastMode = '';
let frameId = 0;

function widthToMode(width) {
  return width >= 420 ? 'wide' : 'compact';
}

function scheduleRender(mode) {
  if (mode === lastMode) return;
  lastMode = mode;
  cancelAnimationFrame(frameId);
  frameId = requestAnimationFrame(() => {
    renderSparkline(mode === 'wide' ? 7 : 3);
  });
}

const observer = new ResizeObserver(([entry]) => {
  scheduleRender(widthToMode(entry.contentRect.width));
});
observer.observe(card);

这段代码的关键不是把所有变化都吞掉，而是把“尺寸发生变化”和“业务模式发生变化”分开。拖动窗口时宽度可能从 421 变到 420，再变到 419；真正需要重新生成数据视图的只有 wide 与 compact 的切换。

用一个可复现的检查场景验证没有重复计算

把卡片分别放入 360px 和 520px 的容器，先确认布局变化来自 @container，再打开 Performance 面板拖动容器。正常结果是：窄容器只有一列，宽容器变成两列；业务渲染函数只在模式切换时调用，而不是每个像素都调用。

const calls = [];
function renderSparkline(days) {
  calls.push({ days, at: performance.now() });
  // 真实项目中在这里更新图表数据，不要改写 card 的宽度
}

如果调用次数仍然持续增长，先检查渲染函数是否改变了被观察元素或其父级的尺寸。观察器最常见的反馈回路是：尺寸变化触发渲染，渲染又改变尺寸，于是下一轮布局再次触发观察。这里别急着加节流，先确认写回动作是否真的必要。

动态组件的清理和兼容边界

卡片由列表框架反复挂载时，观察器必须和组件生命周期绑定。删除节点前调用 observer.disconnect()，同时取消未执行的动画帧。对不支持 container query 的旧环境，可以保留一套默认单列样式；ResizeObserver 也应按项目的浏览器基线决定是否加载兼容方案，而不是在回调中依赖不存在的 API。

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

常见问题：两个 API 能不能互相替代

container query 能直接替代 ResizeObserver 吗？

不能。它负责 CSS 规则匹配，不能触发业务数据计算，也不能读取尺寸交给 JavaScript。

ResizeObserver 回调里可以直接改宽度吗？

尽量不要。直接改动被观察元素或其父级尺寸容易形成反馈回路；如果必须改动，应明确终止条件并在下一帧合并。

为什么只判断宽度还要保存 lastMode？

宽度是连续值，业务布局通常是离散模式。保存上一次模式可以避免同一模式内的无效重绘。

把判断留给 CSS，把计算留给 JavaScript

这套组合的边界很清楚：container query 处理组件的视觉布局，ResizeObserver 处理会影响业务计算的尺寸变化，requestAnimationFrame 负责把同一帧内的通知合并。先按模式去重，再在组件销毁时清理观察器，通常比给整个页面加一个全局 resize 监听更容易维护。