Vue 响应式对象解构后为什么失去更新

在 Vue 3 里，reactive() 返回的是一个响应式代理对象。问题通常出在这一步：把它的普通属性直接解构成局部变量。像 const { count } = state 这样的写法会把当前值取出来，局部 count 不再经过 state 的属性访问代理，所以后续修改 state.count 时，依赖它的界面可能没有更新。

最稳妥的处理方式是：多个属性需要解构时使用 toRefs(state)，只需要一个属性时使用 toRef(state, 'count')；如果没有必须解构的理由，直接保留 state.count 反而最直观。

官方文档：https://vuejs.org/guide/extras/reactivity-in-depth.html

判断口诀：响应式对象的属性访问要留在 Proxy 链路里；要把属性带到局部作用域，就先把它变成仍然指向源属性的 ref。

现象：直接解构后，局部值不再跟随 state

先看一个容易在排障时出现的最小场景。这里的关键不是按钮，而是解构动作本身：primitive 属性被赋给局部变量后，局部变量和源属性已经是两个独立的绑定。

import { reactive, watchEffect } from 'vue'

const state = reactive({ count: 0, label: '待处理' })
// 直接解构只取出当下的值，count 不再指向 state.count
const { count, label } = state

watchEffect(() => {
  // 这里读取的是普通局部变量，不会重新触发 state 的属性追踪
  console.log(count, label)
})

// 源对象会变化，但局部 count 和 label 不会跟着变化
state.count++
state.label = '已处理'

如果现场表现为“state.count 在别处变了，但当前组件显示旧值”，先记录这三个信号：源对象是否仍是 reactive 返回值、是否发生了 primitive 解构、依赖函数里读的是 state.count 还是局部 count。这比先怀疑模板刷新时机更快。

分层检查：Vue 追踪的是属性访问，不是普通变量

Vue 3 的响应式系统依赖运行时的属性访问。reactive() 产生 Proxy，读取 state.count 时可以记录依赖，写入同一属性时再触发相关副作用。直接解构后，count 只是一个局部绑定，读取它不会再次经过 Proxy 的 get。

这解释了一个常见误会：解构并不是所有场景都“破坏响应式”。如果属性本身是对象，解构出的变量仍可能指向那个嵌套代理，对对象内部的变更仍可观察；真正容易断开的，是数字、字符串、布尔值等 primitive 属性的绑定。排查时不要把“解构”三个字当成唯一结论，要继续看属性值的类型和访问路径。

import { reactive, watchEffect } from 'vue'

const state = reactive({
  count: 0,
  profile: { name: '小林' }
})
// primitive 的 count 会失去源属性连接；对象 profile 仍指向嵌套代理
const { count, profile } = state

watchEffect(() => {
  // count 是普通值，profile.name 仍然经过嵌套代理
  console.log(count, profile.name)
})

state.count++
state.profile.name = '小周'

修复动作：用 toRefs 或 toRef 保留属性连接

需要同时拿出多个字段时，用 toRefs() 将当前可枚举属性转换成一组 ref。每个 ref 的 value 仍和源对象属性同步，因此可以放心解构。只需要一个字段时，toRef() 的范围更小，也更适合表达依赖关系。

toRefs(state) 只会为调用时已经存在且可枚举的属性创建 ref。如果字段可能稍后才出现，直接使用 toRef(state, 'fieldName') 更合适；它表达的是“这个 ref 绑定到源对象的这个属性”，而不是“复制一次当前值”。

反向验证：回滚路径与确认清单

如果修复后仍然没有更新，先把解构回滚成 state.xxx，确认问题是否消失。若消失，再按需求选择 toRefs 或 toRef，不要同时改动 nextTick、组件缓存和渲染调度。

• 多个已有字段要返回给组件或 composable 消费者：使用 return toRefs(state)。
• 单个字段、可能后加的字段或需要明确命名的依赖：使用 toRef(state, 'field')。
• 没有解构需求：保留 state.field，减少中间层。
• 处理 props：需要解构时同样使用 toRefs(props) 或针对单字段使用 toRef(props, 'field')。

确认告警时只看一个结果：修改 state.field 后，依赖函数、组件模板或计算结果是否读到了同一条属性连接。不要把旧版 Reactivity Transform 的宏写法当成通用修复方案；当前文档化的 toRefs、toRef 更容易在团队代码中追踪。

常见问题

toRefs 会复制一份对象吗？

不会。它返回的是包含属性 ref 的普通对象，每个 ref 仍指向原 reactive 对象的对应属性，修改任一侧都会同步。

什么时候不该使用 toRefs？

如果只在模板或同一函数内部使用，直接写 state.count 往往更清楚；只有在需要解构、返回 composable 状态或把属性传给外部函数时，才值得增加 ref 层。

总结：先定位是否把 primitive 从 reactive 对象直接解构出来，再决定回滚到 state.field、用单字段 toRef，还是用 toRefs 批量保留响应式。关键不是避免解构，而是不要让局部变量脱离源属性的追踪链。