防抖和节流是同步控制逻辑，async/await仅用于其包裹的异步回调内部；二者本质依赖setTimeout/clearTimeout或时间戳，不因async/await改变；错误做法是用Promise化定时器替代防抖节流。
防抖和节流本身是同步控制逻辑，不依赖 async/await；async/await 用于处理异步操作（如 API 请求、定时器 Promise 化），但不能直接“实现”防抖或节流。真正结合的方式，是在防抖/节流封装的回调函数内部，用 async/await 调用异步任务，同时保持节流/防抖的时序控制不变。
防抖中使用 async/await：等用户停手后再发请求
搜索框输入是最典型场景。你不能在每次 keyup 就 await fetch，否则仍会发出大量请求。正确做法是：先用 debounce 包裹一个 async 函数，确保只有最后一次输入“静默”后才执行异步请求。
- debounce 本身仍是基于 setTimeout + clearTimeout 的同步节制逻辑
- 被包裹的函数可以是 async，内部用 await 调接口，不影响防抖机制
- 注意：不要在 debounce 外层加 await —— debounce 返回的是新函数，不是 Promise
const search = debounce(async (query) => {
const res = await fetch(`/api/search?q=${query}`);
const data = await res.json();
renderResults(data);
}, 300);
input.addEventListener('input', (e) => search(e.target.value));
节流中使用 async/await：滚动时定期加载，避免并发堆积
滚动加载更多时，若每次 scroll 都触发 await fetch，可能因请求未完成就再次触发，导致多个 pending 请求并行，甚至状态错乱。节流可限制调用频率，而 async/await 仅负责单次请求的等待与错误处理。
立即学习“Java免费学习笔记（深入）”；
- throttle 控制“最多每 500ms 执行一次”，不管内部是同步还是异步
- 内部 async 函数的 await 不影响 throttle 的时间判断逻辑（时间戳或定时器仍由 throttle 自己维护）
- 建议配合 loading 状态或取消上一次请求（如 AbortController），防止旧请求返回覆盖新结果
关键提醒：async/await 不改变防抖/节流的本质
防抖靠重置定时器，节流靠时间戳或锁标识——它们都运行在主线程，依赖闭包保存状态。async/await 只是让回调里的异步流程更清晰，并不会：
- 自动帮你去重或延迟执行（那是 debounce/throttle 的事）
- 解决多次调用导致的竞态问题（需手动用 abortSignal 或 isPending 标志位）
- 替代 setTimeout/setInterval（Promise 化定时器只是写法糖，底层仍是宏任务）
进阶技巧：把 setTimeout Promise 化，但慎用
有人会写 await new Promise(r => setTimeout(r, 300)) 来代替 debounce，这是错误的。它无法清除前序延时，也不能响应“新事件到来即重置”，纯属模拟，不具备防抖语义。真正的防抖必须有 clearTimeout 介入。
同理，节流中若用 await sleep(ms)，会导致主线程“假等待”，阻塞后续事件，违背节流本意——节流要的是“跳过执行”，不是“卡住执行”。
