多条件筛选应共用单例防抖定时器，每次任一条件变更时立即采集全量状态快照并重置定时器，300–500ms后仅发起一次请求；重置、显式提交及URL初始化等场景需绕过防抖立即执行。
在商城筛选面板中，多条件（如价格区间、品牌、分类、排序等）联动时，用户频繁操作会导致大量无效请求。防抖的核心是“合并多次触发为最后一次”，但多个输入源需统一控制——不能每个条件单独防抖，否则无法感知组合变化。关键在于：所有筛选条件共用同一个防抖定时器，且每次任一条件变更时，都重新采集当前完整筛选状态并重置定时器。
统一监听 + 状态快照
不给每个筛选项（如价格滑块、品牌复选框、下拉菜单）单独绑定防抖函数，而是监听所有相关 DOM 变化（input、change、click 等），并在回调中立即读取全部筛选字段的当前值，生成一个「状态对象」：
const filters = {
category: selectCategory.value,
brand: Array.from(brandCheckboxes).filter(cb => cb.checked).map(cb => cb.value),
priceMin: priceSlider.noUiSlider.get()[0],
priceMax: priceSlider.noUiSlider.get()[1],
sort: sortSelect.value
};
这个对象就是本次请求的完整依据，后续只基于它发请求，不关心哪个字段变了。
单例防抖函数控制请求节奏
定义一个全局防抖函数（例如 debounceSearch），内部维护唯一 timer。每次任一筛选动作触发时，都调用它，并传入当前 filters 对象和延迟时间（通常 300–500ms）：
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
let searchTimer = null;
function debounceSearch(filters, delay = 400) {
clearTimeout(searchTimer);
searchTimer = setTimeout(() => {
fetchProducts(filters); // 实际请求函数
}, delay);
}
这样无论用户拖动价格滑块 5 次、连点 3 个品牌、再切换排序，只要最后 400ms 内没新操作，就只发起一次携带最新全量参数的请求。
注意边界：显式提交与清空场景
防抖适用于“用户持续调整”，但以下情况应绕过防抖、立即执行：
- 点击「重置筛选」按钮 → 直接清空状态并立即请求默认列表
- 点击「搜索」或「应用」按钮 → 立即触发当前 filters 请求，不等待延迟
- URL 参数首次加载（如分享链接带 filter）→ 初始化时同步请求，不防抖
这些属于明确的用户意图，不应被防抖延迟。
避免常见坑：状态不同步与重复请求
确保每次触发 debounceSearch 前，filters 对象确实是实时、不可变的快照（建议用结构克隆或 Object.assign({}, …) 避免引用污染）；同时在 fetchProducts 中加 loading 状态锁，防止用户快速连续操作导致 timer 清除不及时而发出多个请求：
let isSearching = false;
async function fetchProducts(filters) {
if (isSearching) return;
isSearching = true;
try {
const res = await api.search({ ...filters });
renderList(res.data);
} finally {
isSearching = false;
}
}
不复杂但容易忽略。
