防抖函数执行时机是“等待停顿”而非固定延后，每次新触发重置倒计时，仅最后一次触发后静默 delay 时间才执行；需管理 timer 而非闭包，cancel 应暴露并用于清理定时器，避免内存残留。
防抖函数的执行时机不是“固定延后”，而是“等待停顿”；闭包本身不需“清理”，真正要管理的是定时器引用和内存残留。
防抖的实际触发时机：等用户真正停下来
防抖不是简单地“每次触发都延后 delay 毫秒”，而是每次新触发时重置倒计时——只有在最后一次触发之后，完整经过 delay 时间且中间再无新触发，函数才执行。这个“停顿窗口”才是关键。
- 用户连续输入 5 次，间隔均小于 300ms → 前 4 次全部被取消，只执行第 5 次触发后的回调
- 第 5 次触发后静默 300ms → 回调准时运行
- 若第 5 次触发后 200ms 又有一次输入 → 倒计时再次清零，重新等待 300ms
闭包不是要清理的对象，timer 才是核心管理目标
闭包是实现机制，不是资源泄漏源。真正需要关注的是 timer 变量的生命周期和可访问性：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 闭包让 每个 debounce 实例拥有独立的 timer，这是设计所需，不是 bug
- timer = null 应在 setTimeout 回调末尾手动置空，便于后续判断是否为首次触发（尤其在 immediate 模式下）
- 若不置空，timer 仍持有数字 ID，虽不影响 clearTimeout，但会干扰逻辑判断（如 !timer 不再准确）
- 组件卸载等场景下，应调用 cancel 方法主动 clearTimeout 并 timer = null，避免定时器在已销毁上下文中执行
cancel 方法的本质：提前终止未决的延迟执行
cancel 是对防抖行为的可控退出，不是破坏闭包，而是中断当前 pending 的定时器：
- 它内部执行 clearTimeout(timer)，并通常将 timer 设为 null
- 必须暴露在返回函数上（如 debounced.cancel = () => { ... }），否则外部无法干预
- 在 React useEffect 清理函数、Vue beforeUnmount 等钩子中调用 cancel，可防止 setState on unmounted component 类错误
常见误操作：重复创建导致闭包失控
闭包本身安全，但滥用会导致多个 timer 并存、互相不可见：
- 在事件监听器内反复调用 debounce(...) → 每次生成新闭包、新 timer，旧 timer 失去引用，无法清除
- 正确做法：在模块顶层或组件初始化时定义一次 debouncedFn，然后复用
- React 中推荐配合 useCallback + useRef，确保防抖函数不随渲染重建
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
