防抖函数必须用闭包，因其能为每个实例创建独立作用域并持久保存timer，确保多次调用可清除旧定时器、设置新定时器，同时保障this和参数正确传递，避免全局污染或局部变量失效。
防抖函数必须用闭包，不是为了“炫技”，而是解决一个根本矛盾：如何让多次调用共享同一个定时器控制权。
闭包保存 timer 的必要性
timer 不能定义在事件回调里，否则每次触发都新建一个 timer，clearTimeout 就清不到上一次的；也不能定义在全局，否则多个防抖实例（比如搜索框 + 窗口 resize）会互相覆盖、错乱。
- 闭包把 timer 放在 debounce 工厂函数的作用域中，每次调用 debounce(fn, ms) 都生成独立作用域，各自拥有专属 timer
- 返回的内部函数通过闭包持续引用这个 timer，保证“清除旧的、设置新的”逻辑能跨多次调用生效
- 没有闭包，timer 就只是局部变量，函数一执行完就销毁，防抖就退化成普通延时
闭包维持 this 和参数的传递链
目标函数 fn 执行时需要正确的 this 指向和真实参数，而这些信息在事件触发时才确定。闭包不提前捕获 args，但为透传留出通路：
- 内部函数在被事件调用时，自然拿到当前 this（如 input 元素）和 arguments
- 通过 func.apply(this, args) 把上下文和参数原样交给 fn，避免 this 指向 window 或 undefined
- 如果不用闭包，而是直接在 debounce 内部执行 fn()，this 就会丢失
闭包带来的内存驻留是功能代价，不是 bug
只要防抖函数还被事件监听器引用，它的闭包环境就不会被回收——这是设计使然，不是泄漏。
- timer、func、delay 这些被内部函数实际访问的变量，才会保留在堆中
- 没被用到的变量（比如工厂函数里声明的大数组）不会被闭包捕获，执行完就释放
- 组件卸载或移除监听器后，应主动清除 timer 并解除引用（如设 handler = null），否则闭包长期滞留
不使用闭包的尝试为何失败
常见错误写法是把 timer 声明在事件回调内部或全局，这两种方式都破坏了“单实例状态一致性”：
- 回调内声明：每次触发都 new 一个 timer，clearTimeout(timer) 清的是刚建的，对上一个无效
- 全局声明：多个 debounce 调用共用一个 timer，A 实例设的定时器可能被 B 实例误删
- 只有闭包能提供“每个防抖函数独享状态 + 多次触发可追溯”这一组合能力
