企业官网建设流程全解析

1. 从“响应式”说起：为什么我们需要 ref 和 reactive？

如果你刚开始接触 Vue 3 的 Composition API，面对ref()和reactive()这两个核心 API，心里大概率会冒出一个问号：它们看起来都能创建响应式数据，为什么要有两个？直接用reactive包住所有对象不就好了吗？这个问题，我刚开始也纠结了很久，直到在实际项目中踩了几个不大不小的坑，才真正理解了它们的设计哲学和适用边界。今天，我们就抛开官方文档那些略显抽象的定义，从一个一线开发者的视角，把ref和reactive掰开揉碎了讲清楚。

简单来说，ref和reactive都是 Vue 3 响应式系统的基石，但它们服务的场景和心智模型有本质区别。你可以把ref想象成一个“盒子”，它专门用来封装一个独立的、基础类型的值（如字符串、数字、布尔值），让你能通过.value属性去“打开盒子”访问和修改它。而reactive更像一个“魔法口袋”，你扔进去一个普通的 JavaScript 对象，它会把这个对象连同其内部所有嵌套属性都变成响应式的，你可以直接像操作普通对象一样操作它，无需额外的.value。

这个区别听起来简单，但背后涉及到类型推断、代码组织、与第三方库集成、以及在特定场景（如模板引用、组合函数）下的表现差异。理解不透彻，就容易写出看似能跑但隐患重重的代码，比如在组合函数里错误地返回了reactive对象的一部分导致响应性丢失，或者在不该用.value的地方疯狂点.value。接下来，我们就从原理、用法、场景到避坑指南，一步步深入。

2. 核心原理拆解：响应式系统的两种“包装”策略

要理解区别，必须先明白 Vue 3 响应式系统的底层是如何工作的。Vue 3 抛弃了 Vue 2 基于Object.defineProperty的响应式实现，转而采用了 ES6 的Proxy。Proxy可以拦截对象的基本操作，如读取（get）、设置（set）、删除（deleteProperty）等。reactive()函数正是基于Proxy实现的。

2.1 reactive()：基于 Proxy 的深度代理

当你调用const obj = reactive({ count: 0, nested: { a: 1 } })时，Vue 内部会为这个普通对象创建一个Proxy代理。这个代理是“深度”的，意味着它不仅会监听obj.count的修改，也会递归地将obj.nested这个子对象也变成响应式的。当你访问obj.count时，Proxy的get拦截器会追踪这个依赖（如果是在effect或computed等上下文中）；当你修改obj.count = 1时，set拦截器会触发相应的更新。

关键特性：

• 直接访问：你直接操作obj.count，无需.value。
• 深度响应：嵌套对象自动成为响应式。
• 对象限定：它只接受对象（Object, Array, Map, Set等）作为参数。如果你传一个字符串或数字进去，Vue 会在开发环境下警告你。

2.2 ref()：一个通用的“响应式引用”容器

ref()的设计目标更通用：它要能容纳任何类型的值，包括基础类型（string, number, boolean, null, undefined）和对象引用。由于Proxy无法直接代理基础类型（它们不是对象），Vue 采用了一种“装箱”策略。

当你调用const num = ref(0)时，Vue 实际上创建了一个具有value属性的响应式对象，类似于{ value: 0 }。然后，Vue 对这个.value属性进行了响应式处理。如果传入的是对象，如ref({ count: 0 })，那么ref内部会调用reactive()方法来处理这个对象，最终的效果是num.value成为了一个响应式对象。

关键特性：

• .value 访问：你必须通过.value来读写内部值。
• 类型通用：可以包装任何值。
• 模板自动解包：在模板中直接使用{{ num }}，Vue 会自动帮你解开.value，无需在模板里写.value。但在<script setup>的 JS/TS 逻辑部分，必须显式使用.value。
• 引用稳定：ref创建的响应式引用本身是稳定的，即使内部.value被完全替换（如num.value = ‘newValue’），这个ref变量指向的仍然是同一个容器对象。

2.3 响应性丢失的经典陷阱

这里衍生出一个非常重要的概念：响应式连接（Reactive Connection）。reactive()返回的是一个代理对象，这个代理对象和原始对象是“不同”的。响应性附着在这个代理对象上。

const raw = { foo: 1 }; const reactiveObj = reactive(raw); // 以下操作会导致响应性丢失！ let broken = reactiveObj.foo; // 将基础值赋值给变量，失去连接 let { foo } = reactiveObj; // 解构赋值，失去连接 const passSomewhere = reactiveObj.foo; // 传递给函数，失去连接 // 正确的做法：始终保持对响应式对象“本身”或“其属性（如果是对象）”的引用 const fooRef = toRef(reactiveObj, ‘foo’); // 使用 toRef 创建引用 const { foo } = toRefs(reactiveObj); // 使用 toRefs 解构

而ref通过.value这个统一的接口，强制你始终通过这个容器去访问值，在很大程度上避免了无意中“丢失引用”的问题。当然，如果你把ref.value（一个对象）解构了，同样会丢失响应性。

3. 实战场景下的选择指南：何时用 ref，何时用 reactive？

理论讲完了，我们落到实际编码中。我总结了一个简单的决策流，但这并非铁律，团队规范和个人偏好也很重要。

3.1 优先使用 ref() 的场景

1. 定义基础类型的响应式数据：这是ref的天然主场。

   const loading = ref(false); const username = ref(‘’); const count = ref(0);

2. 定义可能需要被重新赋值的响应式数据：ref的.value可以被整个替换。

   const userInfo = ref({ name: ‘Alice’, age: 30 }); // 未来某个时刻，完全替换数据 const fetchUser = async () => { userInfo.value = await api.fetchUser(); // 整个替换，响应性保持 };

   如果用reactive做同样的事，你需要一个个属性去赋值，或者使用Object.assign(reactiveObj, newData)，但后者在某些极端情况下可能不如ref的整个替换直观。

3. 在组合函数（Composables）中返回数据：这是一个最佳实践。组合函数返回ref可以让使用者明确知道这是一个响应式引用，需要通过.value访问（在JS中），语义更清晰。同时，它避免了使用reactive返回时可能发生的解构响应性丢失问题。

   // useMouse.js - 好的做法 export function useMouse() { const x = ref(0); const y = ref(0); // ... 逻辑 return { x, y }; // 使用者解构后依然是 ref } // 使用 const { x, y } = useMouse(); // x 和 y 仍然是 ref watch(x, (newX) => { console.log(newX); }); // 正常工作

4. 模板引用（Template Refs）：这是ref的特殊用法，用于引用 DOM 元素或子组件实例。

   <template> <input ref=“inputRef” /> </template> <script setup> import { ref, onMounted } from ‘vue’; const inputRef = ref(null); onMounted(() => { inputRef.value?.focus(); // 通过 .value 访问 DOM 元素 }); </script>

3.2 优先使用 reactive() 的场景

1. 定义逻辑紧密关联的对象状态组：当一组状态天然属于同一个对象，并且你很少会需要整体替换这个对象时，reactive用起来更自然。

   const formState = reactive({ username: ‘’, password: ‘’, rememberMe: false, }); // 在模板中直接使用 formState.username，在逻辑中直接修改 formState.password

   相比用多个ref然后组合，reactive保持了数据结构的完整性，在传递给需要对象参数的函数或库时也更方便。

2. 与第三方非响应式库集成：有些库（例如某些图表库、地图 SDK）需要你传入一个配置对象，并且后续会修改这个对象的属性。如果你希望这些修改是响应式的，可以用reactive包装配置对象后传入。

   import * as echarts from ‘echarts’; const chartOption = reactive({ title: { text: ‘销量图表’ }, xAxis: { data: [] }, series: [{ data: [] }], }); const chartInstance = echarts.init(chartDom); chartInstance.setOption(chartOption); // 传入 reactive 对象 // 后续更新数据，视图会自动响应 fetchData().then(data => { chartOption.xAxis.data = data.categories; chartOption.series[0].data = data.values; // 由于 chartOption 是响应式的，这里可能需要配合 chartInstance.setOption 的特定调用 // 但响应式数据能帮你管理状态变化。 });

   注意：这要求该第三方库是直接修改你传入的对象属性，而不是内部创建副本。对于ref，你需要传xxx.value，可能会让库的调用方感到困惑。

3.3 一个常见的混合模式与工具函数

在实际项目中，你很少会只使用其中一种。更常见的模式是混合使用，并借助 Vue 提供的工具函数来桥接它们。

• toRef和toRefs：这是连接reactive世界和ref世界的桥梁。

  • toRef(reactiveObj, ‘key’)：基于reactive对象的一个属性，创建一个与之保持响应式连接的ref。即使原属性不存在，创建的ref也会是响应式的。
  • toRefs(reactiveObj)：将reactive对象的每个属性都转换为一个ref。这在组合函数返回reactive对象时极其有用，可以保证解构不丢失响应性。

  function useFeature() { const state = reactive({ a: 1, b: 2, }); // 返回 toRefs 转换后的结果，方便使用者解构 return { …toRefs(state) }; // 相当于返回 { a: ref(1), b: ref(2) }，且与内部 state 保持连接 }

• unref：这是一个语法糖，unref(x)等价于isRef(x) ? x.value : x。在编写同时接受ref或普通值的工具函数时非常有用。

4. 类型系统 (TypeScript) 下的细微差别

如果你使用 TypeScript，ref和reactive在类型推断上会给你不同的体验。

• ref：类型推断非常直接。const n = ref(0)会推导出Ref<number>。当你访问n.value时，它就是number类型。
• reactive：类型推断同样优秀，但有一个著名的限制：它返回的类型是原对象的响应式代理版本，这个类型会丢失原始类型的个别特性（例如，通过泛型参数传递的构造函数类型）。对于绝大多数日常使用，这没有任何问题。但如果你需要严格保持与原始类型完全一致，有时需要使用类型断言as或markRaw。

在组合函数返回类型上的建议：为了获得最佳的类型推断和开发者体验，组合函数返回一个由ref组成的对象通常是更优的选择。这样在使用方解构时，每个变量的类型都是清晰的Ref<T>。

5. 性能与心智模型考量

在性能上，ref和reactive在绝大多数场景下的差异可以忽略不计，不应作为选型的主要依据。真正的考量在于“心智模型”和代码的可维护性。

• ref的心智模型：你有一个“盒子”，所有操作都通过“打开盒子”（.value）进行。这种显式操作在复杂逻辑中有时反而更清晰，因为它强制你思考“我现在操作的是这个响应式引用本身”。
• reactive的心智模型：你有一个“魔法对象”，像普通对象一样操作即可。这更符合直觉，但你必须时刻警惕“响应性丢失”的陷阱，尤其是在解构和传参时。

我的个人经验是：在组件内部，对于松散的状态，多用ref；对于天然成组的表单数据、页面状态对象，可以考虑用reactive。在编写可复用的组合函数时，除非返回的状态确实是一个紧密的整体对象，否则优先返回ref，或者返回经过toRefs处理的reactive对象。

最后，关于网络热词中提到的“vue3 孙组件 ref 访问”、“将 ref 或 reactive 数据传给 wxs”等问题，其核心都在于理解响应式数据的传递和保持。访问孙组件，需要通过defineExpose显式暴露；跨技术栈传递（如 Vue 到 WXS），则需要序列化或使用特定的桥接方法，因为响应式系统无法跨越运行环境。理解了ref和reactive的本质，这些衍生问题也就有了排查的思路。