防抖函数的取消机制是保障逻辑正确性和组件安全性的必要设计，核心在于通过闭包共享timer变量实现cancel方法对pending定时器的安全干预，且cancel需可重入、清空状态并配合run方法协同工作。
防抖函数的取消机制不是可选附加项，而是保障逻辑正确性和组件安全性的必要设计。它的核心价值在于让调用者能主动干预正在等待执行的定时任务——比如组件卸载前中断 pending 请求、搜索词切换时丢弃旧校验、表单字段快速切换时终止前序验证。
闭包是取消机制成立的前提
取消操作必须能访问并清除那个尚未触发的定时器 ID。这个 ID 不能挂全局（会冲突），也不能每次调用都新建（就找不到上一个）。闭包提供了唯一合理的方案：timer 在外层 debounce 函数中声明一次，返回的防抖函数和 cancel 方法共享同一作用域，外部无法直接读写 timer，但可通过暴露的 cancel 方法安全干预。
- timer 是 let 声明的自由变量，生命周期绑定到该 debounce 实例
- 多个 debounce 调用各自拥有独立的 timer，互不干扰
- 没有闭包，cancel 就成了无源之水——根本拿不到要清的那个 timer
cancel 方法必须可重入且清状态
只写 clearTimeout(timer) 是不够的。真实场景中 cancel 可能被多次调用（比如 React useEffect 清理函数执行两次），或在 timer 已为 null 时调用。健壮实现需主动防御：
- 内部先判断 timer 是否存在，再 clearTimeout，避免重复清除报错
- 清除后立即将 timer 设为 null，既释放引用，也方便后续判断是否已取消
- 主逻辑中也要检查 timer === null，防止 cancel 后误重启定时器
返回结构决定调用方式
只返回一个函数，调用方就无法主动取消。生产级实现应返回对象，明确分离触发与控制职责：
- run 方法封装防抖逻辑，支持传参和 this 绑定（用 func.apply(this, args)）
- cancel 方法专注清理，不依赖 run 是否已执行
- cancel 后再次调用 run，应正常启动新定时器，而非静默跳过
典型使用场景与易错点
cancel 不是写完就扔的装饰代码，它活跃在真实生命周期里：
- React 组件 unmount 前调用 handleInput.cancel()，避免 setState 在已销毁组件上警告
- 搜索框关键词变更时，cancel 上一个请求，防止旧响应覆盖新结果
- 避免在 render 中反复创建 debounce 实例——timer 引用丢失，cancel 失效
- setTimeout 回调内必须在 fn 执行完毕后再设 timer = null，否则 cancel 可能失效
