防抖和节流可协同配合：搜索框用“首字立即触发+后续防抖+节流兜底”，滚动加载以节流为主、防抖收尾，resize采用防抖为主+节流保底，按钮提交结合防抖、状态锁与节流降级。
防抖和节流不是非此即彼的选择，而是可以协同配合的“组合技”。在真实业务中，单一策略常难兼顾响应及时性与执行稳定性，比如搜索框既要避免输入中途频繁请求，又不能等到用户彻底停手才响应——这时就需要分层控频。
搜索框：防抖 + 节流双保险
典型问题：用户快速输入“react”，中间可能误触、删改，若纯防抖（500ms），首次“r”后等待太久；若纯节流（200ms），又会在输入未完成时发多次无效请求。
解法是“首字节立即触发 + 后续防抖 + 最大频率兜底”：
- 第一次输入立即发起请求（提升感知速度）
- 后续每次输入启动防抖（如300ms），覆盖连续输入场景
- 同时用节流限制最小间隔（如800ms内最多2次请求），防止用户狂敲或粘贴导致突发请求洪峰
滚动加载：节流主导 + 防抖收尾
无限滚动常见卡顿点：滚动过程中频繁计算是否触底，但“触底判定”本身需 DOM 查询，开销不小；而用户拖拽到底部后可能微调位置，造成重复加载。
立即学习“Java免费学习笔记（深入）”；
推荐组合：
- 主逻辑用节流（如160ms）控制滚动监听频率，保证每帧不卡顿
- 当节流判定“可能触底”时，再用防抖（如200ms）做最终确认——避免因滚动抖动反复触发加载
- 加载开始后，可临时禁用滚动监听，加载完成再恢复（防抖+状态锁双重防护）
窗口 resize：防抖为主 + 节流保底
用户拖拽调整窗口大小时，事件密集且持续时间长。纯防抖可能迟迟不执行，导致布局错乱；纯节流又可能在缩放中途就强行重排，视觉跳变。
工程化做法：
- 主函数用防抖（300ms），确保窗口稳定后重新计算布局
- 同时设置一个“紧急节流”机制：若连续 1 秒内 resize 触发超 20 次，强制执行一次轻量级适配（如仅更新容器宽度，不重绘内容）
- 利用 requestAnimationFrame 做视觉层节流，让 UI 更新节奏匹配屏幕刷新率
按钮防重复提交：防抖 + 状态锁 + 节流降级
表单提交按钮点击连点，不仅要防重复请求，还要应对网络异常、接口超时等边界情况。
- 点击时先用防抖（如800ms）拦截短时重复点击
- 提交发起后立即置为 loading 状态（UI 层硬锁）
- 若请求超时或失败，允许用户在节流窗口（如2s）后再次点击，避免“永远无法重试”
- 关键操作（如支付）还可叠加唯一请求 ID + 后端幂等校验，前端防抖节流只是第一道防线
