说实话，从 Vue 2 转战 Vue 3 的那段时间，我简直是在“踩坑”与“填坑”的循环中度过的。Composition API kan起来是那么优雅，代码组织也变得前所未有的灵活。但是当你满怀信心地在 setup 函数里写下第一行解构赋值代码时噩梦可Neng就开始了。

你有没有遇到过这种情况：父组件传过来的数据变了子组件里却纹丝不动？你盯着控制台kan了半天数据明明geng新了视图却像死了一样。这时候，你大概率是掉进了“解构 props 导致响应性丢失”的经典陷阱里。今天咱们就掰开揉碎了聊聊这事儿，顺便kankan怎么避开这些坑。

咱们先来还原一下“案发现场”。假设你正在开发一个用户信息展示组件，父组件传了一个 user 对象进来。在 setup 里为了代码写得好kan点，你顺手就解构了：

export default {
  props: ,
  setup {
    // kan起来hen简洁，对吧？
    const { name, age } = props.user
    // 然后你在某个方法里或者模板里用到了 name
    // ...
    return { name, age }
  }
}

这时候，Ru果父组件里的 user.name 发生了变化，你猜怎么着？子组件里的 name 根本不会动！它就像是一个被定格的快照，永远停留在第一次渲染时的值。这种沉默的 Bug 往往Zui难排查，因为它不会报错，只是静静地“摆烂”。

要搞清楚原因，咱们得先钻进 Vue 3 的内核里kankan。Vue 3 的响应式系统是基于 ES6 的 Proxy 构建的。这玩意儿hen强大，它Neng拦截对象的读取、赋值等操作，从而让 Vue 知道数据变了需要去geng新视图。

但是Proxy 也是有脾气的。它只Neng追踪到它所包裹的那个对象本身。

为了方便理解，咱们打个比方。想象一下props 就像是一根连接着水源的水管，水在水管里源源不断地流动。

当你直接使用 props.user.name 时就像是每次dou去水管口接水喝。水源变了你接出来的水自然也就变了。

但是当你执行 const { name } = props.user 这一步解构操作时情况就变了。这相当于你拿了一个杯子，从水管里接了一杯水出来放在了桌子上。这时候，杯子里的水和水管里的水Yi经没有物理上的连接了。哪怕水管里的水后来变成了红色，或者停止流动了你杯子里的那杯水依然保持着原来的样子。

在 JavaScript 的世界里解构操作本质上就是值的拷贝。你把 name 这个字符串或者数字拿出来赋值给了一个新变量，这个新变量就是一个普普通通的 JS 变量，Vue 的 Proxy 根本管不着它。既然管不着，自然也就失去了响应性。

那是不是说我们就不Neng解构了？每次dou得写 props.xxx.xxx 这么长的前缀吗？那也太反人类了。别急，Vue 官方早就给我们准备了“解药”——toRefs。

这个工具函数的作用非常神奇：它Neng把一个响应式对象转换成一组普通的 ref 对象。每一个转换出来的属性，dou依然保持着和原数据源的连接。

Ru果你需要解构 props 里的多个属性，toRefs 是Zui佳选择。它会遍历 props 对象，把每一个 key dou变成一个 ref。

import { toRefs } from 'vue'
export default {
  props: ,
  setup {
    // 注意这里！我们把 props 整个传给了 toRefs
    const { user } = toRefs
    // 现在 user 是一个 ref 对象了
    // 在模板里或者 JS 里使用时记得它是 ref
    console.log 
    return { user }
  }
}

这里有个细节要注意：toRefs 只Neng处理响应式对象。Ru果你解构的是 props.user，那情况又有点不一样。通常情况下props 本身是由 Vue 包装的响应式对象，所以对 props 使用 toRefs 是Zui稳妥的。

有时候，你可Neng只需要 props 里的某一个特定属性，不想把整个对象dou转一遍。这时候，toRef 就派上用场了。

import { toRef } from 'vue'
export default {
  props: { title: String, count: Number },
  setup {
    // 只把 title 转成 ref
    const title = toRef
    // 这样 title 就是一个响应式的 ref 了
    // 它的值变化会追踪到 props.title 的变化
    return { title }
  }
}

除了在模板里展示数据，我们在 setup 里还经常需要监听数据的变化来执行副作用，比如发请求。

kankan下面这段代码，是不是hen眼熟？

setup {
  const { id } = props // 错误示范：直接解构
  // 你想监听 id 的变化去请求数据
  watch => id,  => {
    fetchData
  })
}

这就完蛋了。因为 id 是一个静态值，watch 里的 getter 函数每次返回的dou是同一个初始值。当父组件的 props.id 变了这里的 id 根本不知道，fetchData 自然也就不会被触发。

正确的姿势应该是这样：

import { watch } from 'vue'
setup {
  // 不要解构，直接在 watch 里写 getter 函数
  watch(
     => props.id, 
     => {
      console.log
      fetchData
    }
  )
}

或者，Ru果你非要在逻辑里用解构后的变量，那就得用前面提到的 toRefs，然后在 watch 里使用 .value

import { toRefs, watch } from 'vue'
setup {
  const { id } = toRefs
  watch => {
    fetchData
  })
}

有同学可Neng会问：“Ru果是解构一个对象，比如 props.user，那会丢失响应性吗？”

这个问题问得好。基本类型在解构时是值拷贝，这hen好理解。但引用类型在解构时拷贝的是内存地址。

这意味着，Ru果你解构 const user = props.user，然后修改了 user.name = 'newName'，虽然 user 这个变量本身不是响应式的，但是你修改 user.name 依然可Neng会触发视图geng新。为什么？因为 user 指向的还是原来那个被 Proxy 包裹的对象内部。

但是！千万别依赖这个特性！这非常危险。因为一旦你在某个地方把 user 重新赋值了连接就彻底断了。而且，这种代码的可读性极差，维护起来简直是噩梦。所以不管是基本类型还是引用类型，在 setup 里处理 props，请务必统一使用 toRefs 或者老老实实写 props.xxx。

聊了这么多痛点，Zui后得给大家来点好消息。Vue 3.5 版本其实Yi经针对这个问题Zuo了hen大的优化。

在早期的 Vue 3 版本中，我们使用