deep: true 在大型嵌套对象上性能开销显著，首次依赖收集可达8–15ms，每次变更触发全量递归比对，且加剧proxy内存占用；推荐用精准路径监听替代。
直接评估 watch 配置 deep: true 在大型嵌套对象上的性能消耗，核心看三件事：首次依赖收集耗时、每次变更触发的遍历开销、以及内存中 Proxy 实例的累积量。它不是“慢一点”，而是可能从 0.1ms 跳到 10ms+，尤其在节点多、层级深、字段杂的场景下。
首次监听时的依赖收集成本
启用 deep: true 后，Vue 会在侦听器创建瞬间，递归访问目标对象每一层可枚举属性，为每个访问路径建立响应式依赖。这不是静态扫描，而是真实执行 getter 拦截——意味着：
- 一个含 200 个字段、5 层嵌套的对象，可能触发数千次
get拦截，耗时常达 8–15ms - 若对象里有循环引用或大量函数/不可枚举属性，还会额外增加判断逻辑，进一步拖慢初始化
- 这个过程发生在组件 setup 或 onBeforeMount 阶段，会阻塞渲染，用户可能感知到卡顿
每次数据变更带来的重复遍历
只要被监听对象任意子属性变化（哪怕只改了 user.profile.avatar），deep: true 就会再次全量遍历整个结构，比对新旧值。问题在于：
- 比对不是浅比较，而是逐字段递归 JSON.stringify 级别的深度相等判断（尤其对数组、Map）
- 即使你只更新一个字段，Vue 仍要确认其他 199 个字段没变，这属于冗余计算
- 高频更新（如输入框实时同步、动画状态刷新）会放大该开销，容易引发回调抖动
Proxy 实例与内存压力
深层监听本身不直接创建更多 Proxy，但它强烈依赖 reactive 对象的代理链完整性。而大型嵌套对象用 reactive() 初始化时，已按需生成大量嵌套 Proxy：
- 每层对象（如
user→profile→address）都对应独立 Proxy 实例 - 100 个用户节点 × 平均 4 层深度，轻松产生 400+ Proxy，占用额外内存与 GC 压力
- 这些 Proxy 不仅用于 watch，还参与所有依赖收集——UI 渲染、computed 计算、其他 watch 全部共享这套开销
更轻量的替代方案
不必放弃监听能力，关键是把“监听什么”和“怎么监听”拆开处理：
- 用计算函数精准监听路径：
watch(() => user.settings.theme, cb)，跳过无关字段，单次耗时通常 - 结构稳定时限制深度：
deep: 3（Vue 3.5+ 支持），避免无意义穿透到第 5、6 层 - 把大对象拆成多个细粒度 ref：
userProfile = ref()、userStats = ref()，分别监听各自关心的部分 - 纯展示型数据（如配置项、菜单树）用
markRaw()+shallowRef()，彻底绕过响应式系统，需要时再局部 reactive
