关键是在watcheffect回调内部对异步操作（如api请求、dom测高）做debounce封装，而非包裹整个watcheffect；需在setup顶层定义防抖函数并onbeforeunmount清理。
在 watchEffect 中结合 lodash.debounce 实现输入防抖侦听，关键不是“把 debounce 套在 watchEffect 外面”，而是用它控制副作用内部的异步执行节奏——因为 watchEffect 本身会高频重跑，必须防止每次重跑都触发请求或计算。
watchEffect 不适合直接 debounce 包裹
watchEffect 的设计是“响应式依赖一变就立即重新执行整个回调”。如果你对整个回调做 debounce，会导致：依赖更新后不立刻重跑，失去响应性；甚至因防抖延迟造成状态错乱（比如用户已清空输入，但防抖还在等下一次触发）。所以不能对 watchEffect(() => {...}) 整体做 debounce。
正确做法是：在 watchEffect 回调内部，只对**真正需要防抖的副作用操作**（如 API 请求、DOM 测高、复杂过滤）做 debounce 封装。
推荐写法：在回调里调用防抖后的函数
将防抖逻辑封装为独立函数，在 watchEffect 中按需调用。例如搜索场景：
- 定义防抖函数（setup 中一次性创建，避免重复实例化）：
const debouncedFetch = debounce((query) => { if (query.trim()) api.search(query) }, 300) - 在
watchEffect中读取响应式变量，并触发它：watchEffect(() => { debouncedFetch(searchQuery.value) }) - 组件卸载前清理定时器：
onBeforeUnmount(() => debouncedFetch.cancel())
为什么这个组合更可靠？
它保留了 watchEffect 的自动依赖追踪能力（searchQuery 变、主题字体变、容器宽变，都会触发重跑），同时把开销大/需节制的操作交由 debounce 控制频率。
相比 watch + debounce 的写法，这种组合更适合多变量联动场景——比如搜索框还受“当前语言”“筛选标签”影响，你无需在 watch 里手动列数组依赖，watchEffect 会自动感知所有被读取的响应式值。
补充：防抖函数建议封装为组合式函数
为复用和统一管理，可抽成 useDebouncedFn：
- 接收目标函数和延迟时间
- 返回防抖函数，并在组件卸载时自动
cancel() - 调用时传参自由，支持 Promise 返回值处理（如 loading 状态同步）
这样多个 watchEffect 或事件处理器都能共享同一套防抖逻辑，且无内存泄漏风险。
