“最大调用堆栈”错误本质是watch回调中同步修改了被监听字段，导致无限递归触发；常见于监听form.name却在回调中赋值form.name，应改用v-model.trim或更新非监听字段，避免deep:true滥用，优先使用computed处理派生值。
监听器报错“最大调用堆栈”，本质是 watch 回调里无意触发了自身再次执行，形成同步无限调用。这不是 Vue 的 bug，而是响应式闭环没断开——读取一个值 → 修改它 → 再次触发 watch → 再修改……直到 JS 调用栈撑爆。
别在 watch 里直接改监听的字段
这是最常见也最容易踩的坑。比如监听 form.name，回调里又写 form.name = newVal.trim()，等于自己喊自己起床，一喊就响，一响再喊。
- ✅ 正确做法：输入规范化交给 v-model.trim 或事件处理（如 @input、@change）
- ✅ 必须在 watch 中更新？确保目标字段和监听字段不重叠，例如监听 name，更新 displayName 或 searchQuery
- ❌ 错误示例：watch(() => form.name, val => { form.name = val.trim() }) —— 直接改源，必死循环
慎用 deep: true，尤其别在回调里动嵌套属性
开启 deep: true 后，watch 会监听整个对象所有层级。一旦你在回调中修改了对象内部任意属性（比如 user.profile.avatar），很可能再次触发同一 watch，特别是当这个对象还被 computed 或其他 watch 引用时。
- ✅ 优先精准监听：用 watch(() => obj.field) 替代 watch(obj, ..., { deep: true })
- ✅ 真需监听深层变化？确保回调内只读不写，或只写完全无关的独立状态
- ✅ 派生数据优先用 computed：它天然缓存、无副作用，不会主动触发更新
检查 computed 和其他 watch 是否隐式联动
表面看是一个 watch 在跑，实际背后可能串着一长串依赖链：watch A 改了 filterText → 触发 computed B 重新求值 → computed B 被 watch C 监听 → watch C 又改了 filterText……闭环悄悄闭合了。
- ✅ 在 watch 开头加 console.log('xxx watch triggered')，观察触发频率和顺序
- ✅ 临时注释掉疑似相关的 computed 或其他 watch，逐步隔离问题模块
- ✅ 用 Vue Devtools 查响应式依赖图，重点看“谁读了谁、谁改了谁”，比纯猜快得多
区分 computed 和 watch 的分工
computed 是“算出来一个值”，watch 是“值变了之后做点事”。如果在 computed 里发请求、改 ref、调 API，它就会因依赖变化反复执行，极易引发堆栈溢出。
- ✅ 有副作用（发请求、弹窗、路由跳转、更新另一个状态）？一律用 watch
- ✅ 只是基于已有数据派生新值（如 fullName = firstName + lastName）？用 computed
- ✅ 不确定该用哪个？问自己：这个逻辑要不要触发 DOM 更新或外部行为？要 → watch；不要 → computed
