自定义事件防抖的核心是延迟执行事件分发并在重复触发时重置计时器，需在触发端控制 dispatchEvent 节奏，而非监听端；应每次新建 CustomEvent、合理克隆 detail，并保持与原生事件解耦。
在自定义事件触发器中结合防抖，核心是**延迟执行事件分发，且在延迟期内重复触发时重置计时器**，从而避免高频调用导致的“事件风暴”。关键不在事件本身是否自定义，而在于你控制“何时真正 dispatchEvent”。
防抖逻辑必须包裹事件派发动作
不能只对监听器做防抖（那是消费者的事），而要在触发端（trigger 端）控制派发节奏。例如：
class DebouncedEventTarget extends EventTarget {
constructor() {
super();
this._debounceTimers = new Map();
}
// 触发带防抖的自定义事件
dispatchDebouncedEvent(type, detail = {}, options = { delay: 100 }) {
const { delay } = options;
const key = type; // 可按 type 或 type+key 组合去重
// 清除已存在的定时器
if (this._debounceTimers.has(key)) {
clearTimeout(this._debounceTimers.get(key));
}
const timer = setTimeout(() => {
this.dispatchEvent(new CustomEvent(type, {
detail,
bubbles: true,
cancelable: true
}));
this._debounceTimers.delete(key);
}, delay);
this._debounceTimers.set(key, timer);
}
}
这样每次调用 dispatchDebouncedEvent('data-updated')，都会重置防抖计时，确保 100ms 内只发出一次事件。
支持多事件独立防抖与手动取消
实际场景中，不同事件或同一事件的不同上下文可能需要各自独立防抖。可通过扩展 key 策略实现：
立即学习“Java免费学习笔记（深入）”；
- 用
type + JSON.stringify(detail?.id)作为 key，实现按数据 ID 防抖（如每个用户更新单独防抖） - 暴露
cancelDebounce(type, key?)方法，允许外部主动清空某次防抖（比如表单取消时） - 防抖 delay 可动态传入，而非写死——例如搜索框输入可设 300ms，滚动节流可设 50ms
注意事件对象不可复用与细节一致性
CustomEvent 实例不能跨次 dispatch 复用（会报错或行为异常），每次都要新建；同时要保证 detail 是浅拷贝或结构化克隆（尤其含函数或 Symbol 时需谨慎）：
- 避免
detail: this._lastData直接引用——后续修改会影响事件内值 - 推荐用
detail: {...this._lastData}或structuredClone(this._lastData)（兼容性需检查） - bubbles/cancelable 等选项应在每次创建时显式声明，不要依赖默认值隐含行为
与原生事件共存时保持语义清晰
不要把防抖逻辑混进原生事件监听（如 input 或 scroll 的监听里做 dispatch），而应封装成独立能力：
- 原生事件监听器只负责采集和节流/防抖后调用
dispatchDebouncedEvent - 业务方订阅
'data-updated'这类语义化事件，不关心是否防抖——实现与接口分离 - 调试时可通过打日志或 DevTools 的 Event Listener Breakpoints 观察实际派发频率
