防抖和节流本身不会导致内存泄漏，但错误实现易引发内存泄漏和副作用；需正确清除定时器、透传this与参数、隔离状态、复用函数实例并确保引用稳定。
防抖和节流本身不会导致内存泄漏，但错误的实现方式或不当的使用场景容易引发内存泄漏和副作用。关键不在“用了防抖/节流”，而在“怎么用”和“怎么写”。
避免闭包中残留定时器引用
防抖函数依赖 setTimeout，若未正确清除旧定时器，或在组件卸载、事件解绑前未调用 cancel，残留的定时器会持续持有函数上下文，阻止垃圾回收。
- 每次调用防抖包装函数时，必须先
clearTimeout(timeoutId)，再设置新定时器 - 返回的防抖函数应暴露
cancel()方法，并在组件销毁（如 React 的useEffect清理函数、Vue 的beforeUnmount）中主动调用 - 禁止将定时器 ID 存在全局变量或非闭包作用域中，否则多个实例会互相覆盖或无法清理
防止 this 和参数丢失引发隐式副作用
防抖函数内部若直接用箭头函数包裹原函数（如 () => fn()），会导致 this 固化、事件对象等参数丢失，进而使 handler 逻辑异常（比如 DOM 操作找不到目标元素、表单提交拿不到值）。
- 推荐用
func.apply(this, arguments)或展开语法func(...args)显式透传上下文与参数 - 绑定固定上下文时，用
fn.bind(context)预处理，而非在防抖内硬编码this - 避免在防抖内部直接写
event.preventDefault()等副作用操作——应由原始 handler 自行处理
节流中状态标记需严格隔离
节流函数常用 isThrottled 标志位控制执行节奏。若该变量未被闭包完全封闭，或多个节流实例共用同一变量，就会出现“本该执行却跳过”或“本该限制却连发”的副作用。
立即学习“Java免费学习笔记（深入）”；
- 每个节流函数实例必须拥有独立的
isThrottled（或时间戳）状态，不能依赖外部共享变量 - 不推荐用
Date.now()做时间判断而不缓存上次执行时间——高频率调用下可能因毫秒精度丢失导致误判 - 节流函数也应提供
cancel()或flush()方法，在必要时强制执行或重置状态
监听器解绑前务必清理防抖/节流实例
给 DOM 元素绑定事件时，若直接传入每次调用都新建的防抖函数（如 el.addEventListener('scroll', debounce(handler, 100))），会导致多个闭包长期驻留内存，且无法统一清理。
- 防抖/节流函数应在模块或组件初始化阶段创建一次，并复用该实例
- 移除事件监听器时，必须传入与绑定时完全相同的函数引用（即同一个防抖包装函数），否则
removeEventListener失效 - 现代框架中（如 React），优先在
useCallback中定义并 memoize 防抖函数，确保引用稳定
