resize事件需防抖而非节流，因其高频连续触发（Chrome每帧可能触发），节流会遗漏中间关键断点（如992px），而防抖只响应最终稳定尺寸，契合响应式布局“只关心结果”的需求。
直接用 window.addEventListener('resize', callback) 就能监听，但不加防抖会在拖拽窗口时疯狂触发，卡顿或重复计算是常态。
为什么 resize 事件要防抖而不是节流
resize 是连续高频事件，比如 Chrome 在窗口拖拽过程中每帧都可能触发；节流会强制固定间隔执行，容易错过中间关键尺寸（如从 1200px 拖到 768px 时跳过 992px 这个断点）；防抖则只响应“最终稳定状态”，更符合响应式布局的真实需求。
- 防抖适合：调整布局、重绘图表、切换 CSS 类等“只关心结果”的场景
- 节流适合：需要持续反馈的场景（如拖拽预览），但窗口 resize 几乎不用它
- 推荐延迟值：
200–250ms—— 太短起不到抑制作用，太长会让用户感觉响应迟钝
获取窗口尺寸该用 innerWidth 还是 clientWidth
两者语义不同，选错会导致移动端适配出 bug：
-
window.innerWidth：含滚动条的视口宽度，**响应式断点判断首选**，它和 CSS 媒体查询里的width完全对应 -
document.documentElement.clientWidth：不含滚动条的可视区域宽，适合计算元素可渲染空间（比如 Canvas 画布大小） - 别用
document.body.clientWidth：在某些 DOCTYPE 下 body 可能不占满 viewport，值不可靠 - 移动端注意：软键盘弹出会触发 resize，但
innerWidth在部分 Android 浏览器中可能不变，此时需结合window.visualViewport?.width判断
ResizeObserver 能替代 window.resize 吗
不能直接替代，它是不同维度的工具：resize 监听整个视口，ResizeObserver 监听**单个元素**的 content-box 尺寸变化。
立即学习“前端免费学习笔记（深入）”；
- 想响应“浏览器窗口缩放”或“设备横竖屏切换”？必须用
resize事件 - 想响应“某个卡片因 flex 分配变宽”或“文本增多导致容器撑高”？用
ResizeObserver更精准、性能更好 - 两者可共存：比如用 resize 做断点切换，用 ResizeObserver 动态调整内部子元素比例
- 注意兼容性：
ResizeObserver在 IE 中完全不可用，resize事件 IE9+ 都支持
真正容易被忽略的是：resize 回调里读取的尺寸，和实际渲染帧可能不同步；如果依赖 DOM 布局结果（比如要拿某个元素 offsetHeight），得用 requestAnimationFrame 包一层，否则可能读到旧值。
