防抖和节流是优化高频事件性能的两种策略：防抖在事件停止触发后延时执行一次，适用于搜索输入等需最终结果的场景；节流则按固定间隔最多执行一次，适用于滚动监听等需稳定反馈的场景。
防抖（Debounce）和节流（Throttle）是前端处理高频事件的两种经典策略，核心目标都是减少函数实际执行次数，从而避免不必要的计算、DOM操作或请求，提升页面响应速度和运行效率。
防抖：等“停下来”再执行
防抖的逻辑是：只要事件持续触发，就不断重置定时器；只有事件停止触发一段时间后（比如 300ms），才真正执行一次函数。典型场景是搜索框输入联想、窗口大小调整后的重新布局。
- 适合用户行为有“连续性”且只需最终结果的场景，比如输完关键词再发请求
- 实现关键：每次触发都清除上一个定时器，再新建一个
- 注意点：首次触发不会立刻执行，需等待静默期；若想立即执行可加 leading 选项（非默认）
节流：固定频率“匀速执行”
节流的逻辑是：无论事件触发多频繁，在指定时间间隔内最多只执行一次函数。常见于滚动监听、鼠标拖拽、游戏帧更新等需要稳定节奏的场景。
- 适合需要持续反馈但不必每次响应的场景，比如滚动时判断是否进入视区
- 实现方式常见有两种：时间戳法（记录上次执行时间）、定时器法（用开关控制）
- 注意点：节流会牺牲部分实时性来保性能，间隔设太长可能影响交互体验
它们怎么优化性能？
高频事件（如 resize、scroll、input）在毫秒级内可能触发数十次，若每次回调都做 DOM 查询、样式重排或发请求，浏览器很快就会卡顿甚至崩溃。防抖和节流通过控制执行频次，直接降低以下开销：
立即学习“Java免费学习笔记（深入）”；
- 减少 Layout/Repaint 次数，避免强制同步布局（Layout Thrashing）
- 降低 JS 主线程占用，让 UI 渲染更流畅
- 节省网络资源，防止重复请求（尤其搭配防抖做搜索建议）
- 缓解内存压力，避免闭包或事件监听器堆积
简单对比与选型建议
防抖强调“最后一步”，节流强调“稳定节奏”。选择看需求：
- 用户输入后查数据 → 用防抖（等他打完）
- 滚动中实时显示位置 → 用节流（每 100ms 更新一次）
- 既想立刻响应又想控频 → 可组合使用（如 Lodash 的
throttle({ leading: true, trailing: true })）
基本上就这些。不复杂但容易忽略，写对了能明显感觉到页面变顺。
