watch 是被动监听器，防抖需包裹回调逻辑而非修改配置；推荐300–500ms延迟；须统一管理定时器并组件卸载前清除；避免监听源与副作用耦合；防抖内需校验空值与竞态。
Watch 本身不控制触发频率，它只是响应式系统对数据变化的被动监听器。要避免高频变更引发的频繁回调，必须把防抖逻辑加在 watch 的执行环节——不是改 watch 配置，而是让它的回调“等一等、挑一挑”再执行。
防抖函数要包裹实际业务逻辑，不是 watch 配置
watch 的作用是“发现变了”，但变多少次、怎么响应，得由你决定。直接在回调里发请求或更新状态，等于每变一次就干一次，必然过载。
- 正确做法：用 debounce 包一层真正的操作，比如
fetchSuggestions()或validateForm() - 错误做法：在 watch 回调里写一堆 if-else + setTimeout，逻辑散乱且 timer 容易失控
- 推荐延迟值：搜索类场景常用 300–500ms；表单校验可设 200ms；太短起不到效果，太长影响反馈感
定时器引用必须统一管理，组件卸载前务必清除
防抖靠 clearTimeout 取消上一次计划，如果 timer 变量作用域不对、被重复声明或没清理，旧任务可能还在后台执行，导致状态错乱或内存泄漏。
- Options API 中：在 data 里定义
debounceTimer: null，watch 回调中先clearTimeout(this.debounceTimer)，再赋新setTimeout - Composition API 中：用
let timer = null声明在 setup 顶层，比 ref 更轻量；配合onBeforeUnmount(() => timer && clearTimeout(timer))确保安全退出 - 若用 Lodash：调用
debounce(fn, ms).cancel()主动取消待执行任务，尤其适合清空输入框或切换页面时
注意监听源和副作用之间的隔离
有些场景下，watch 回调里又改了被监听的数据，会触发新一轮 watch，形成循环或打断防抖节奏。
- 避免监听对象后在回调中直接修改该对象属性（如
user.name = newValue），容易引发深层响应连锁 - 搜索框建议监听字符串 ref（如
searchKey），而不是整个表单对象；需要深层字段时，优先用计算属性收敛依赖 - 若回调中需更新 UI 状态（如 loading、suggestions），用独立 ref 控制，不反写监听源
结合空值与竞态控制提升健壮性
防抖只解决“频次”，不解决“该不该做”。用户输空格、删到空、快速切词，都可能产生无效请求或结果错位。
- 在防抖函数内部加校验：
if (!value?.trim() || value.length - 对异步请求加 AbortController：新请求发起前
abortController.abort()，丢弃上一个未完成响应 - 必要时用时间戳标记请求顺序，返回结果时比对当前最新时间戳，过期则忽略
