computed负责派生值并缓存，watch（含deep:true）负责响应变化并执行副作用；二者定位不同，应按“计算用computed、响应用watch”分层协作，避免误用导致性能损耗。
Vue 中的深度监听（deep: true）和 computed 的缓存机制本身并不直接冲突，但它们在使用场景、触发逻辑和性能表现上存在天然张力——这种张力常被误读为“冲突”，实则是设计定位不同导致的协作边界问题。
深度监听 watch 的本质是“响应变化”，不是“计算派生”
当你给 watch 配置 deep: true，Vue 会递归遍历对象（或数组）的所有嵌套属性，为每个响应式子属性建立监听。这意味着：
- 哪怕只改了
obj.user.profile.name，整个obj都会被视为“变化”，触发 handler； - handler 每次都执行，无缓存，无论实际变更是否影响业务逻辑；
- 它适合做副作用：比如发请求、更新本地存储、重置 UI 状态等。
注意：deep 监听开销较大，尤其对深层嵌套或大对象，频繁触发会明显拖慢响应速度。
computed 缓存的前提是“依赖可追踪且稳定”
computed 依赖的是明确、静态的响应式路径（如 state.obj.a 或 props.list.length）。它的缓存生效需满足两个条件：
立即学习“前端免费学习笔记（深入）”；
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- 依赖项必须是响应式数据（ref/reactive），且访问路径固定；
- 函数体内不能有无法被 Vue 追踪的动态行为（例如
Object.keys(obj)、for...in遍历、或直接读取非响应式字段）。
一旦你试图用 computed 去“深度派生”一个对象（比如 computed(() => JSON.stringify(obj))），就绕过了响应式追踪——Vue 不知道 obj 内部哪个字段变了，只能靠字符串化“暴力比对”，这既失去缓存意义，又带来额外计算开销。
真正容易出问题的典型场景
以下写法看似合理，实则破坏缓存或引发冗余执行：
-
用 computed 包裹深拷贝或 JSON 操作：
computed(() => _.cloneDeep(data))—— 每次返回新对象，缓存失效，且无实际派生价值； -
在 watch deep 中反复赋值触发 computed 重新求值：比如监听
form并在 handler 里执行form.items.push(...)，若 computed 依赖form.items，每次 push 都会触发重算，但若 items 是 ref 数组，直接 push 已能被追踪，无需 deep； -
混淆监听目标与计算目标：想过滤列表却用
watch: { list: { deep: true, handler() { this.filtered = ... } } }，而其实computed: { filtered() { return this.list.filter(...) } }更简洁、自动缓存、且响应更精准。
如何协调二者：按职责分层
记住一句话：computed 负责“产出确定值”，watch 负责“响应不确定变化”。
- 如果逻辑是“从 A 和 B 推出 C，且 C 只随 A/B 变”，一律用 computed；
- 如果逻辑是“当 X 的任意部分变了，我要发请求/清缓存/重绘 Canvas”，才用
watch: { x: { deep: true } }； - 若 deep 监听后需派生新数据，优先提取关键字段做 computed（如
watch: { 'user.profile.avatar': () => {...} }），避免监听整个 user 对象； - 必要时组合使用：watch 深度响应外部变更 → 触发 ref 更新 → computed 自动基于新 ref 重新缓存计算。
本质上没有冲突，只有错配。用对地方，watch 和 computed 各司其职，反而形成高效协作链。
