Vue 3 的 reactive 采用懒递归代理实现深度监听，仅在首次访问时逐层代理可响应式对象，跳过原始类型和不可代理内置对象，ref 的深度能力也源于此机制。
Vue 3 的 reactive 默认就是深度监听的，但它不是“一口气递归到底”，而是“用到哪一层，才代理哪一层”——这个机制叫懒递归代理。
深度监听 ≠ 一次性全量代理
当你写 reactive({ a: { b: { c: 1 } } })，Vue 并不会立刻把 a、b、c 所在的对象全部转成 Proxy。它只做最外层对象的代理，内部嵌套结构保持原样。
- 首次读取
state.a→ 触发get拦截 → 发现a是普通对象 → 立即调用reactive(a)创建新 Proxy，并缓存 - 后续访问
state.a.b→ 再次触发get→ 对b执行相同逻辑，继续代理 - 如果某条路径从未被访问（比如
state.x.y），那对应对象根本不会被代理，也不产生开销
所有合法嵌套类型都自动参与递归
reactive 会识别并递归处理以下类型的值：
- 普通对象（
{}）和数组（[]） - Map、Set、WeakMap、WeakSet
- 但跳过原始类型（
string、number、boolean、null、undefined）和内置不可代理对象（如Date、RegExp、Promise）
也就是说，只要嵌套结构里出现一个可代理对象，它就会被“接上响应式链”，无需手动标记或配置 deep: true。
ref 其实也走同一套深度逻辑
别被 ref 的表象迷惑：ref({ x: { y: 1 } }) 底层等价于：
reactive({ value: reactive({ x: reactive({ y: 1 }) }) })
所以 myRef.value.x.y 的变化，一样能被精确追踪和触发更新——它的深度能力，本质上来自 reactive 的递归代理机制。
深度监听带来的实际影响
这种设计带来两个关键结果：
-
精准依赖收集：模板中只用了
{{ state.user.profile.name }}，那只有这三级路径被 track；改state.user.settings.theme不会触发该组件更新 - 潜在性能代价：如果对象层级深、节点多，又频繁访问不同分支，可能生成大量 Proxy 实例，占用内存并拖慢初始化
需要控制代理范围时，可以用 shallowRef、shallowReactive 或 markRaw 显式终止递归。
