应节流控制并精准判断尺寸变化：设定100–250ms时间阈值限制resize触发频率，缓存并比对window.innerwidth/innerheight避免无意义执行；局部变化优先用resizeobserver；组件卸载时务必清除监听器防内存泄漏。
监听窗口大小变化时，直接绑定 resize 事件容易导致高频触发、性能下降甚至卡顿。关键在于节流控制 + 精准判断实际尺寸变化。
使用节流（throttle）限制执行频率
浏览器在拖拽窗口或缩放时会连续触发数十次 resize，但多数场景只需响应最终尺寸。推荐用时间阈值节流：
- 设定最小间隔（如 100–250ms），两次调用之间强制等待
- 避免用防抖（debounce），因用户可能持续调整，防抖会延迟到停止后才执行，错过中间关键状态
- 可借助 Lodash 的
throttle，或手写简易版本（记录上一次执行时间戳，差值不足则跳过）
只在尺寸真正变化时执行逻辑
节流后仍可能触发无意义调用（如窗口微调但宽高未变）。建议缓存上一次的 window.innerWidth 和 window.innerHeight，仅当任一值不同再更新：
- 避免重复计算布局、重绘 DOM 或触发媒体查询判断
- 尤其对响应式图表、栅格系统、自适应字体等依赖具体像素值的场景很有效
- 注意：Safari 在地址栏展开/收起时也会触发 resize，但 innerWidth 不变，此判断可自然过滤
监听更精准的容器尺寸变化（可选进阶）
若业务聚焦于某区块（如侧边栏、内容区）的尺寸变化，而非整个窗口，可结合 ResizeObserver：
- 原生 API，专为监听元素尺寸变化设计，不依赖窗口事件
- 自动处理 padding/border/content-box 变化，且性能优于轮询
- 兼容性良好（Chrome 64+/Firefox 69+/Edge 79+；旧版可用 polyfill）
- 适合卡片折叠、导航栏切换、动态加载区域等局部响应场景
移除监听器防止内存泄漏
组件卸载或模块销毁时，务必清除 resize 监听：
- 使用
addEventListener绑定时，保存函数引用以便removeEventListener移除 - 避免使用匿名函数绑定，否则无法精确解绑
- React 中可在
useEffect清理函数里移除；Vue 中在beforeUnmount执行 - 单页应用中未清理易导致旧组件逻辑持续运行，消耗 CPU 且引发异常渲染
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
