防抖和节流是事件响应策略而非性能优化技巧，防抖只执行最后一次触发（如搜索输入、resize），节流保证固定间隔执行（如滚动监听、拖拽），选错会导致交互逻辑错误。
防抖和节流不是“性能优化技巧”，而是事件响应策略——它们不直接降低 CPU 占用或减少内存，而是避免函数被高频、无意义地调用。真正拖慢 UI 的，是那些本可跳过的 DOM 计算、布局重排、网络请求或状态更新；而防抖与节流，就是帮你在交互节奏和执行成本之间做取舍。
防抖：只信“最后一次”
每次触发都清掉旧定时器，只在停止触发后 delay 毫秒执行一次。适合结果比过程重要的场景：
- 搜索框输入：用户打完 “vue” 停顿 250ms 后才发请求，中间删改、补全都不触发
- 窗口 resize：等用户彻底拖完再重算栅格、更新图表尺寸，避免边拖边重绘
- 表单失焦校验：光标移出时才检查邮箱格式，而不是每输一个字符就报错
节流：要“节奏感”，不要“全漏掉”
保证函数至少每 interval 毫秒执行一次，不管触发多密。适合需要感知过程但不能太密的交互：
- 滚动监听：每 100ms 读一次 scrollTop，用于吸顶导航、滚动进度条或懒加载判断
- 鼠标拖拽：每 60ms 更新一次元素位置，既流畅又避开帧率瓶颈
- 游戏按键：空格射击设为 throttle(fn, 200)，实现“每 200ms 最多一发”，而非防抖导致的连按变单发
关键区别不在“快慢”，而在“语义”
选错不是性能差一点，而是交互逻辑错了：
立即学习“Java免费学习笔记（深入）”；
- 用防抖处理滚动百分比显示 → 用户滚动时界面静止，松手才跳变，体验断层
- 用节流处理搜索请求 → 用户刚打完字就发请求，还没输完就返回无关结果
- resize 用节流 → 窗口缩小时频繁重排，可能卡顿；用防抖则稳得多
实战避坑要点
写法和使用方式直接影响效果稳定性：
- 别在事件监听里现场 new 防抖/节流函数：每次渲染都生成新闭包，定时器引用丢失 → 提前定义并复用
-
记得绑定 this 和参数：原生事件回调中 this 是 DOM 元素，防抖/节流包装后需用
fn.apply(this, arguments)或展开参数 - delay / interval 要合理：搜索建议 200–300ms，表单校验 400–500ms；节流间隔低于 16ms（1帧）意义不大，还可能加重负担
- 节流注意首次执行时机：时间戳版默认首次立即执行；如需“首次也等间隔”，得用定时器版并控制 leading/trailing
