防抖和节流是针对不同高频事件场景的互斥策略：防抖适用于“等用户彻底停手再执行”（如搜索、resize），节流适用于“必须定期响应但不能太密”（如拖拽、滚动）；二者需根据是否需要最终状态或过程反馈来选择，且均非性能银弹，须先优化回调函数本身。
防抖和节流不是“选一个就行”的通用方案，而是针对不同高频事件场景的两种互斥策略：防抖适合“等用户彻底停手再执行”，节流适合“必须定期响应但不能太密”。
防抖（debounce）：输入框搜索、窗口 resize 后延时执行
典型表现是：连续触发事件时，只在最后一次触发后延迟执行一次。比如用户快速输入 5 个字符，debounce 会忽略前 4 次，只在停止输入 300ms 后调用一次搜索函数。
关键点：
-
setTimeout必须在每次新触发时clearTimeout，否则旧定时器仍会执行 - 首次触发是否立即执行？取决于实现——带
immediate参数的版本可支持“先执行再等待”，但多数搜索场景不需要 - 返回的函数需绑定正确
this和参数，建议用func.apply(context, args)而非直接调用
function debounce(func, wait, immediate = false) {
let timeout;
return function(...args) {
const later = () => {
timeout = null;
if (!immediate) func.apply(this, args);
};
const callNow = immediate && !timeout;
clearTimeout(timeout);
timeout = setTimeout(later, wait);
if (callNow) func.apply(this, args);
};
}节流（throttle）：鼠标拖拽、滚动监听中控制执行频率
典型表现是：无论事件触发多频繁，函数最多每隔 wait 毫秒执行一次。比如滚动事件每 16ms 触发一次，throttle 可将其限制为每 100ms 最多执行一次。
立即学习“Java免费学习笔记（深入）”；
常见陷阱：
构建 Shopify 嵌入式应用（Embedded App）的开发技能：基于 @shopify/shopify-app-react-router + React Router v7 + Admin API 2026-04。覆盖 shopifyApp 配置、authenticate.admin 的 GraphQL/REST 调用、Webhook 校验、Session 存储、订阅计费、App Bridge 导航、部署，并新增：适用场景判断、安全最佳实践、错误处理与容错、最佳实践、常见问题 FAQ、高级场景。G
- 时间戳版节流在首次触发时立即执行，但最后一次触发若不足间隔，则被丢弃；定时器版可保证“最后兜底”，但实现更复杂
- 不要把
throttle和 CSS 的pointer-events: none混用——后者阻断事件，前者只是降频 - 若依赖实时坐标（如拖拽位置），节流会导致视觉卡顿，此时应优先考虑
requestAnimationFrame替代
function throttle(func, wait) {
let previous = 0;
return function(...args) {
const now = Date.now();
if (now - previous >= wait) {
func.apply(this, args);
previous = now;
}
};
}怎么选？看事件是否需要“最终状态”还是“过程反馈”
输入框搜索、表单校验、自动保存——这些操作只关心用户“最终输入了什么”，用 debounce 更合理；而 Canvas 绘图、滚动视差、游戏按键响应——这些依赖中间状态的场景，throttle 或 requestAnimationFrame 才合适。
性能影响差异：
-
debounce在高频期完全不执行，内存占用低，但响应有延迟 -
throttle保持固定节奏，CPU 占用略高，但行为可预测 - 两者都应避免在回调中做重渲染（如直接操作 DOM），推荐结合
useCallback（React）或手动缓存计算结果
现代替代方案：requestAnimationFrame 有时比两者都合适
当目标是“每帧最多更新一次 UI”，比如监听 scroll 更新 sticky 导航栏位置，requestAnimationFrame 比 throttle(16) 更精准，且天然与浏览器刷新节奏同步。
注意点：
- 它不适用于需要精确毫秒控制的逻辑（如音频同步）
- 需手动管理
rafId并在组件卸载/事件解绑时cancelAnimationFrame - 不能直接替代防抖——它不解决“停手后才执行”的需求
let rafId = null;
function animateScroll() {
// 更新 UI
rafId = requestAnimationFrame(animateScroll);
}
// 启动
rafId = requestAnimationFrame(animateScroll);
// 清理
if (rafId) cancelAnimationFrame(rafId);真正容易被忽略的是：防抖和节流本身不是性能银弹。如果回调函数里做了深克隆、正则全局匹配或未加索引的数组遍历，再怎么节流也救不了。先定位瓶颈，再决定用哪个“流控开关”。
