vue响应式系统深层嵌套性能瓶颈源于reactive默认递归代理，导致大量冗余proxy实例与依赖收集；应按需选用shallowreactive、shallowref、markraw与readonly等分层策略优化。
Vue 响应式系统在处理深层嵌套对象时，会默认递归创建代理，这带来显著的性能开销——不是“会不会慢”，而是“在哪慢、为什么慢、怎么绕开”。关键不在 Proxy 本身，而在默认 reactive() 的无差别深度处理策略。
深层遍历从初始化就开始消耗资源
调用 reactive({ a: { b: { c: { d: 1 } } } }) 时，Vue 3 不是只给顶层对象加 Proxy，而是逐层向下：为对象 a、b、c、d 各自创建独立 Proxy 实例，并建立对应的依赖映射（targetMap 中的多层 Map
- 初始化阶段就执行完整递归，无法懒加载或按需代理
- 即使某个子属性从未被模板或 computed 访问，也会被提前代理
- 大型静态配置（如菜单路由、地区列表）用 reactive 包裹，纯属浪费
依赖收集和更新扩散远比想象中冗余
模板中写 {{ node.children[0].name }}，看似只读一个字段，实际触发链是：get(node) → get(children) → get(0) → get(name)。每一步都调用 track()，分别在 targetMap 中为 node、children、数组索引 0、name 四个目标注册依赖。但真正变化的可能只是 name；而修改它时，trigger() 又会沿整条路径向上通知，导致无关的 node 和 children 也触发副作用刷新。
- 渲染访问引发多层依赖，但业务逻辑往往只关心某几个字段
- 叶子节点变更，却让父级、祖父级响应式对象全部重运行 effect
- 数组索引访问（如 list[5].title）同样触发整条路径拦截，无法跳过中间层
冻结与标记容易失效的隐藏风险
Object.freeze() 或 markRaw() 本意是跳过响应式处理，但在嵌套场景下极易被绕过。例如：父对象用 reactive 包裹，其某个子属性值是已 freeze 的对象，一旦对该子对象解构赋值（const { address } = user.profile）或深拷贝后重新挂载，Vue 仍可能对 address 内部属性再次 apply reactive——因为 freeze 只阻断自身代理，不阻止父级 proxy 对其内部属性的 get/set 拦截。
- markRaw() 必须在数据进入 reactive 前调用，顺序错即失效
- 解构、展开运算符、JSON.parse(JSON.stringify()) 等操作会剥离原始标记
- 接口返回的 userInfo.profile.address 这类纯展示字段，不应参与响应式系统
更合理的分层响应式策略
不追求“全响应”，而是按字段角色精准选择 API：
- 列表容器用 shallowReactive：监听数组 length 和 push/pop，跳过所有 item 的深层代理
- 大块静态数据（如菜单配置、原始树结构）用 shallowRef：ref.value 是普通对象，不触发任何响应式遍历
- 真正需要响应的字段（如表单输入的 title、开关状态 isPublished）单独抽成 ref 或 computed
- 纯展示型嵌套结构（如 userInfo.profile.address）用 readonly(markRaw(obj)) 组合，彻底隔离响应式系统
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
