页面一缩放就卡？聊聊窗口大小事件的避坑指南

想象一下这个场景：你辛辛苦苦画好了一套后台管理系统的可视化大屏，图表精美，布局工整。用户正看得满意，随手拖动浏览器边缘调整了一下窗口宽度。瞬间，页面上的柱状图开始抽搐，表格错位，甚至整个布局像喝醉了酒一样抖动起来。用户皱眉，你也跟着头大。

这通常是因为我们在处理 window 的 resize 事件时，忽略了它的“脾气”。

在浏览器原生机制里，当用户改变窗口大小时，resize 事件会被高频触发。如果你在滚动条拖动的每一像素变化中都去重新计算 DOM 布局或发送请求，JavaScript 引擎根本忙不过来。特别是涉及到复杂的绘图库或者大量节点操作时，主线程被阻塞，页面卡顿就成了必然。频繁的事件回调是性能杀手，这一点在老旧浏览器和低端移动设备上尤为明显。

那怎么解决？最简单的思路是控制执行的频率。

这里有两个经典手段：防抖（Debounce） 和 节流（Throttle）。对于窗口调整这种操作，我们更推荐“防抖”，即等用户停止拖拽一段时间后再执行逻辑。比如设置 300 毫秒的等待期，期间如果继续触发事件就重置计时器，只有当用户完全停手后才真正运行你的代码。

下面是一个轻量级的封装示例，直接复制就能用：

function debounce(func, wait) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => func.apply(this, args), wait);
  };
}

// 使用示例
window.addEventListener('resize', debounce(() => {
  // 在这里执行重绘或计算逻辑
  updateLayout(); 
}, 300));

这段代码的核心在于清除上一次未完成的定时器。这样无论用户拉多快，函数在同一时间窗口内只会执行一次，既保证了交互的及时性，又避免了资源浪费。

不过，如果你关注的是某个具体 div 的大小变化，而不是整个浏览器窗口，传统的 resize 事件就不够精确了。现代前端开发有了更优解：ResizeObserver API。

它允许你专门监听特定元素尺寸的改变，不需要再去劫持全局窗口事件。这对于响应式组件非常友好，能实现更细腻的适配。例如，一个卡片组件内部的文字排版，完全可以交给 ResizeObserver 独立处理，互不干扰。这意味着我们可以把全局监听拆分成局部监听，降低系统耦合度。

当然，技术没有万能药。有些老项目依然要兼容 IE，这时候 ResizeObserver 派不上用场，还得依靠 Polyfill 或者回到传统的 resize 方案上。这时候，除了防抖，记得不要在回调里做太耗时的同步计算。如果是复杂的数据重算，异步处理往往能让界面保持流畅，哪怕数据还没出来，UI 也能先给反馈。

说到底，监听窗口大小只是为了让内容更好地呈现，而不是为了炫技。

在实际业务中，建议先评估是否需要实时响应。很多情况下，利用 CSS 的媒体查询（Media Queries）或者 Flex/Grid 布局自动流式排列，比手动写 JS 判断宽窄要稳健得多。JS 应该只处理那些 CSS 无法解决的逻辑，比如基于尺寸的 canvas 重绘。

处理好这些细节，你的页面在面对用户的随意拖拽时，才能真正做到从容不迫，稳稳当当。毕竟，用户体验就藏在这些不被察觉的流畅之中。