窗口 resize 事件需节流处理，推荐 150ms 时间阈值，仅当 innerWidth 或 innerHeight 真实变化时执行逻辑，并优先用 ResizeObserver 监听局部容器，卸载时务必清理监听器防止内存泄漏。
窗口大小调整（resize）事件天然高频，拖拽边框时每秒可触发数十次，直接执行布局计算或 DOM 更新极易引发卡顿。节流不是“加个 setTimeout 就完事”，关键在控制频率 + 排除无效变化 + 及时清理。
用时间阈值做基础节流（100–250ms）
节流的核心是设定最小执行间隔，避免连续响应。推荐 150ms 左右——足够过滤抖动，又不会明显延迟最终状态感知。
- 别用防抖：用户可能持续拉伸窗口，防抖会等到最后才执行，中间关键尺寸（比如从桌面宽缩到平板宽）会被跳过
- 手写简易节流即可，无需引入 Lodash：记录上一次执行时间戳，当前时间减去它，不足阈值就 return
- 注意 this 和 event 参数：节流包装后需正确绑定上下文，并透传原生事件对象（如需访问
event.target）
只在真实尺寸变化时才更新逻辑
节流后仍可能触发无意义调用——比如 Safari 地址栏收起时触发 resize，但 window.innerWidth 没变；或用户微调 1px 窗口，实际不影响响应式断点。
- 缓存上一次的
innerWidth和innerHeight值 - 每次节流回调里比对当前值，仅当任一维度不同再执行后续逻辑（如重算栅格、更新图表容器、切换媒体查询类名）
- 这对依赖像素值的场景特别有效：自适应字体、Canvas 重绘、ECharts 容器 resize 等
局部容器用 ResizeObserver 替代全局 resize
如果业务只关心某个模块（如侧边栏宽度、内容区高度）的变化，监听整个窗口反而低效且耦合。
立即学习“Java免费学习笔记（深入）”；
-
ResizeObserver是浏览器原生 API，专为监听元素尺寸变化设计，不依赖事件循环，性能更好 - 它自动忽略滚动、聚焦等无关触发，只在盒模型真正改变时通知
- 组件卸载时记得调用
observer.disconnect()，否则造成内存泄漏
务必清理监听器防止内存泄漏
页面级 resize 监听器若未清除，即使组件已销毁，回调仍持有作用域引用，导致 DOM 节点无法回收。
- 使用
addEventListener时，保存 handler 引用，卸载前调用removeEventListener - 若用闭包封装节流函数，确保 handler 是同一引用（不要每次创建新函数）
- React/Vue 等框架中，在
useEffect的 cleanup 或beforeUnmount钩子中统一移除
