vue3中lodash debounce导致组件卸载后仍触发，因其闭包持有回调引用且未清理定时器，易引发内存泄漏和运行时错误。
组件卸载后防抖函数的回调还在执行，说明闭包捕获了已失效的上下文（比如 ref、state、this），而防抖器本身又没被销毁——它像一个“幽灵定时器”，持续持有旧组件的引用，导致脏数据写入、重复请求、甚至报错。
看防抖函数是否还在触发副作用
最直接的判断方式是观察组件销毁后是否仍有以下行为：
- 控制台继续打印日志（比如防抖回调里的
console.log） - 网络面板出现本不该发起的请求（如搜索防抖触发的
fetch） - 状态更新报错：例如
Cannot update a component while unmounting或Maximum update depth exceeded - 页面卡顿或内存持续上涨（尤其在反复打开/关闭同一组件时）
检查防抖实现是否自带清理机制
原生 lodash.debounce 和多数封装不提供自动清理能力。它返回的是一个函数，但不会跟踪组件生命周期。常见错误写法：
- 在
setup或useEffect内直接调用debounce(fn, 300)，却没保存 debounced 函数引用，也没在卸载时调用cancel() - 把防抖函数赋给
ref或响应式变量，但没在onBeforeUnmount/useEffect cleanup中显式调用其cancel方法 - 使用第三方防抖 Hook（如
useDebounceCallback），但传入的回调里直接读取了未冻结的props或ref.current
定位闭包是否锁住了组件实例
打开 Chrome DevTools → Memory 面板 → 拍摄堆快照 → 筛选 (closure) → 找到占用大的闭包项：
- 点开它的 Scope 面板，确认是否包含
vm（Vue 2）、currentInstance（Vue 3）、props、state或大型数组 - 查看 Retainers 树：若路径为
Window → global variable → debounceFn → Closure → Component instance，就坐实了泄漏 - 对比两次快照，重点关注
DebouncedFunction类型对象是否持续增长
修复防抖闭包的典型做法
核心原则：让防抖函数能被主动取消，且回调不依赖易失效的上下文。
- Vue 3：
onBeforeUnmount(() => debouncedSearch.cancel())，其中debouncedSearch是ref或let声明的防抖函数 - React：
useEffect(() => () => debouncedHandler.cancel(), [])，确保 cleanup 返回的是同步取消逻辑 - 避免在防抖回调里直接访问
ref.current或props；改用useRef存快照值，或把必要参数提前解构传入 - 慎用
debounce包裹整个异步操作（如debounce(async () => {...})），应只包裹触发逻辑，异步部分内部自行判断组件是否存活
