防抖与节流适用场景不同：防抖适用于事件停止后响应，如搜索联想、表单校验；节流适用于过程持续反馈，如滚动监听、鼠标追踪。二者实现逻辑、触发时机及易错点均存在本质差异。
防抖与节流不是“选哪个更好”，而是“在哪种场景下用哪个更准”。核心在于判断：你关心的是事件停止后的结果，还是事件过程中的节奏控制。
防抖适用场景：等“静下来”再干活
适合那些需要用户操作稳定后才响应的场景。关键特征是：中间过程不重要，最后一次输入/动作才是有效信号。
- 搜索框联想：用户每敲一个字都触发 input，但只在停顿（如300ms）后发请求，避免大量无效查询
- 表单实时校验：输入邮箱时，不必每个字符都校验格式，等用户打完、光标移走前再验证一次
- 窗口 resize 后重排布局：浏览器可能在几毫秒内连续触发数十次 resize，防抖可确保只在最终尺寸确定后执行一次适配逻辑
节流适用场景：按固定节奏持续响应
适合那些需要持续反馈、但又不能无节制执行的场景。关键特征是：过程本身有价值，要均匀采样、保底执行。
- 滚动监听：实现“滚动到某区域触发动画”或“滚动加载更多”，每16ms或200ms检测一次位置，既流畅又不卡顿
- 鼠标移动追踪：游戏或绘图应用中记录轨迹，不需要每像素都记录，按固定间隔取点即可
- 按钮高频点击限制：比如“提交订单”按钮，设为每3秒最多响应一次，防止误触连点
代码实现的关键差异点
两者看似都用 setTimeout 或时间戳，但控制逻辑完全不同：
- 防抖靠“清旧启新”：每次触发都 clearTimeout + 重新 setTimeout，timer 变量始终只管“下一次该不该执行”
- 节流靠“守时放行”：要么用时间戳比对 now - lastTime ≥ delay，要么用定时器锁（running 标志位），确保单位时间内最多进一次函数体
- 立即执行支持不同：防抖的 immediate 模式是“首次立刻干，后续等静默”；节流的 immediate 更多是“首次立刻干，之后按间隔干”，二者语义不可互换
容易踩坑的细节
写错一行，效果就偏航：
- 防抖函数里忘了 clearTimeout(timer)，会导致多个定时器堆积，最后全执行
- 节流用时间戳版却没处理“最后一次未触发”的情况，滚动到底部时可能漏掉加载逻辑（需配合 trailing 参数或 setTimeout 尾调用补救）
- 没正确绑定 this 和 arguments，导致 fn.apply(this, args) 失效，尤其在 addEventListener 中直接传入防抖/节流函数时
- 延迟时间设得太小（如 10ms）或太大（如 2s），前者起不到优化作用，后者明显感知卡顿或响应迟钝
