防抖和节流是事件响应策略而非性能优化技巧，防抖只执行最后一次触发（如搜索输入、resize），节流保证固定间隔执行（如滚动监听、拖拽），选错会导致交互逻辑错误。

防抖和节流不是“性能优化技巧”，而是事件响应策略——它们不直接降低 CPU 占用或减少内存，而是避免函数被高频、无意义地调用。真正拖慢 UI 的，是那些本可跳过的 DOM 计算、布局重排、网络请求或状态更新；而防抖与节流，就是帮你在交互节奏和执行成本之间做取舍。

防抖：只信“最后一次”

每次触发都清掉旧定时器，只在停止触发后 delay 毫秒执行一次。适合结果比过程重要的场景：

• 搜索框输入：用户打完 “vue” 停顿 250ms 后才发请求，中间删改、补全都不触发
• 窗口 resize：等用户彻底拖完再重算栅格、更新图表尺寸，避免边拖边重绘
• 表单失焦校验：光标移出时才检查邮箱格式，而不是每输一个字符就报错

节流：要“节奏感”，不要“全漏掉”

保证函数至少每 interval 毫秒执行一次，不管触发多密。适合需要感知过程但不能太密的交互：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 滚动监听：每 100ms 读一次 scrollTop，用于吸顶导航、滚动进度条或懒加载判断
• 鼠标拖拽：每 60ms 更新一次元素位置，既流畅又避开帧率瓶颈
• 游戏按键：空格射击设为 throttle(fn, 200)，实现“每 200ms 最多一发”，而非防抖导致的连按变单发

关键区别不在“快慢”，而在“语义”

选错不是性能差一点，而是交互逻辑错了：

• 用防抖处理滚动百分比显示 → 用户滚动时界面静止，松手才跳变，体验断层
• 用节流处理搜索请求 → 用户刚打完字就发请求，还没输完就返回无关结果
• resize 用节流 → 窗口缩小时频繁重排，可能卡顿；用防抖则稳得多

实战避坑要点

写法和使用方式直接影响效果稳定性：

• 别在事件监听里现场 new 防抖/节流函数：每次渲染都生成新闭包，定时器引用丢失 → 提前定义并复用
• 记得绑定 this 和参数：原生事件回调中 this 是 DOM 元素，防抖/节流包装后需用 fn.apply(this, arguments) 或展开参数
• delay / interval 要合理：搜索建议 200–300ms，表单校验 400–500ms；节流间隔低于 16ms（1帧）意义不大，还可能加重负担
• 节流注意首次执行时机：时间戳版默认首次立即执行；如需“首次也等间隔”，得用定时器版并控制 leading/trailing

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南