防抖适用于窗口调整后只执行最终布局重算，节流适用于需保持频率的视觉同步；防抖延迟200–300ms，节流间隔100–160ms；真实项目常混合使用，并注意内存泄漏与兼容性。
窗口大小调整（resize事件）是典型的高频触发场景——用户拖拽浏览器边框时，每毫秒都可能触发多次。若在监听函数中直接执行重绘、重排或图表渲染等操作，极易造成主线程阻塞、页面卡顿甚至内存泄漏。防抖和节流都能优化，但适用逻辑不同，关键看你的需求是“等停手再干”，还是“按节奏稳干”。
用防抖处理 resize：适合布局重算类操作
当调整窗口后需重新计算元素尺寸、更新响应式栅格、重绘 ECharts 图表等，这类操作**不需要实时响应中间状态，只关心最终结果**。防抖能确保只在用户完全停止拖拽后执行一次，避免大量无效计算。
- 延迟时间建议设为 200–300ms：太短起不到过滤作用，太长会让用户感觉“滞后”
- 推荐使用 Lodash 的
_.debounce，简洁可靠：
<script src="https://cdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js"></script>
window.addEventListener('resize', _.debounce(() => {
recomputeLayout();
resizeChart();
}, 250)); - 如需手写，核心就是每次触发时清除旧定时器、重设新定时器
用节流处理 resize：适合视觉反馈或动画同步
某些场景下你希望**保持一定频率的响应**，比如同步 canvas 动画尺寸、更新滚动指示器位置、或做轻量级 DOM 样式微调。这时节流更合适——它保证每隔固定时间至少执行一次，不会完全“憋着等停手”。
- 典型间隔设为 100–160ms（接近 60fps 帧率），兼顾流畅与性能
- 时间戳实现简单稳定：
function throttle(fn, delay) {
let last = 0;
return () => {
const now = Date.now();
if (now - last >= delay) {
fn();
last = now;
}
};
}
window.addEventListener('resize', throttle(updateCanvasSize, 120));
实际项目中的混合策略
真实业务往往不是非此即彼。例如一个仪表盘页面：
- 主布局重排用 防抖（300ms）——用户松手后统一刷新容器宽高
- 顶部进度条宽度同步用 节流（60ms）——需要平滑跟随缩放过程
- 避免在 resize 中直接操作大量 DOM 或发起请求；可先记录尺寸变化，交由 requestIdleCallback 或 nextTick 批量处理
额外注意点
现代浏览器已支持 ResizeObserver，它比 resize 事件更精准、更高效，尤其适合监听单个元素尺寸变化。但对于整个窗口尺寸监听，resize 仍是标准方案。不过要注意：
- 务必在组件卸载或页面离开前移除监听器，防止内存泄漏
- 移动端 Safari 对 resize 触发不敏感，有时需配合
orientationchange补充监听 - 服务端渲染（SSR）应用首次 hydration 时，要检查
window是否存在，避免报错
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
