Vue 3里的computed props到底怎么用？这些细节你得搞懂

computed props是干啥的？和普通变量有啥不一样？

你可以把computed props理解成“自动跟数据变化的计算器”，它基于Vue的响应式系统，依赖其他响应式数据，当这些依赖变了，computed的值会自动更新；要是依赖没变化，它就复用之前计算的结果，不会重复执行。

举个生活里的例子：点外卖时，购物车的“总价”就是典型的computed props，它依赖“商品单价”和“购买数量”这两个数据——只要其中一个变动（比如加购商品、修改数量），总价会自动重新计算；要是啥都没动，总价就保持上次结果，不用每次打开购物车都重新算一遍。

和普通变量的区别更直观：假设用普通变量存总价，得手动更新——

let total = 0;  
// 商品数量或单价变化时，得手动写代码更新total  
total = price * count;  

这时候一旦漏写更新逻辑,总价就会和实际数据脱节，但用computed的话，Vue会自动盯紧依赖，依赖一变就自动更新，完全不用手动操心。

computed和methods有啥区别？为啥不用methods代替？

很多新手会疑惑：“methods也能写逻辑，为啥还要用computed？” 核心区别在“缓存机制”上。

methods里的函数,每次调用都会重新执行，比如模板里写<div>{{ formatTime() }}</div>，不管数据变没变，每次组件渲染（哪怕只是父组件传参变化导致重渲染），formatTime都会重新跑一遍。

但computed是“依赖不变就复用结果”——只有依赖的响应式数据变化时，才会重新计算；否则直接返回缓存结果。

举个性能差异明显的例子：做“已完成的待办列表”，用methods的话：

methods: {  
  filteredTodos() {  
    return this.todos.filter(todo => todo.done);  
  }  
}  
// 模板里用{{ filteredTodos() }}  

每次组件渲染（比如新增一个todo，不管是否已完成），filteredTodos都会重新过滤整个列表，数据多了就容易卡顿。

换成computed则完全不同：

computed: {  
  filteredTodos() {  
    return this.todos.filter(todo => todo.done);  
  }  
}  
// 模板里用{{ filteredTodos }}  

只有todos本身变化（比如新增、删除、修改某个todo的done状态）时，filteredTodos才会重新计算，其他无关的渲染（比如父组件传了个不相关的props），直接复用缓存结果，性能友好很多。

Vue 3里怎么声明computed？基础语法和选项式API有啥不同？

Vue 3有选项式API和组合式API两种写法，computed的声明方式差异很大，得根据项目技术栈选择。

选项式API（适合Vue 2迁移项目）

在组件的computed选项里写函数，函数名就是计算属性名，返回值为计算结果：

export default {  
  data() {  
    return {  
      firstName: '张',  
      lastName: '三'  
    };  
  },  
  computed: {  
    fullName() {  
      return this.firstName + this.lastName;  
    }  
  }  
};  

模板里直接用{{ fullName }}（不用加括号）。

组合式API（Vue 3推荐，更灵活）

需要先从vue导入computed函数，再用const 计算属性名 = computed(回调函数)声明，回调函数返回计算后的值：

import { ref, computed } from 'vue';  
export default {  
  setup() {  
    const firstName = ref('张');  
    const lastName = ref('三');  
    const fullName = computed(() => {  
      return firstName.value + lastName.value;  
    });  
    return { fullName }; // 暴露给模板使用  
  }  
};  

注意：组合式API里用ref时，需通过.value访问值（因为ref是包装对象）；但模板里不用写.value，Vue会自动解包。

可写的computed（带setter）

有时需要“双向绑定”计算属性（比如用户输入全名，拆分成名和姓），这时候要给computed加set函数：

选项式API：

computed: {  
  fullName: {  
    get() {  
      return this.firstName + this.lastName;  
    },  
    set(newValue) {  
      // 假设全名是“姓+名”，拆分前1个字符为姓，后面为名字  
      this.firstName = newValue.slice(0, 1);  
      this.lastName = newValue.slice(1);  
    }  
  }  
}  

组合式API：

const fullName = computed({  
  get() {  
    return firstName.value + lastName.value;  
  },  
  set(newValue) {  
    firstName.value = newValue.slice(0, 1);  
    lastName.value = newValue.slice(1);  
  }  
});  

这样在模板里给fullName赋值（比如<input v-model="fullName" />）时，setter会触发，自动更新firstName和lastName。

computed的缓存机制咋工作的？啥时候会失效？

computed的缓存逻辑可以简单理解为：“只在依赖的响应式数据变化时，才重新计算”。

Vue会自动跟踪computed函数里用到的响应式数据（比如ref、reactive里的属性），并将这些数据标记为“依赖”，只要其中一个依赖变化，下一次访问computed时就会重新执行计算函数、更新结果；如果依赖都没变，直接返回缓存结果，跳过计算。

看个例子：

const count = ref(1);  
const double = computed(() => count.value * 2);  
console.log(double.value); // 输出2（首次计算）  
count.value = 2;  
console.log(double.value); // 依赖count变化，重新计算→输出4  
console.log(double.value); // 依赖无变化，复用缓存→输出4  

缓存失效的常见场景

如果computed里用了非响应式数据，缓存机制会“失效”（本质是computed没察觉到数据变化）。

let num = 1; // 普通变量，非响应式  
const result = computed(() => num * 2);  
num = 2;  
console.log(result.value); // 还是2，因为num不是响应式，computed没发现它变了  

解决方法很简单：把普通变量用ref或reactive包装成响应式数据：

const num = ref(1);  
const result = computed(() => num.value * 2);  
num.value = 2;  
console.log(result.value); // 输出4，正常更新  

复杂场景下，computed咋处理多依赖和嵌套？

实际项目中,computed常依赖多个响应式数据，甚至依赖另一个computed，这时要注意逻辑分层和避免副作用。

多依赖场景：多个响应式数据共同决定结果

比如计算“满减后价格”，依赖“原价”和“折扣率”：

const price = ref(100);  
const discount = ref(0.8);  
const finalPrice = computed(() => {  
  return price.value * discount.value;  
});  
// 当price或discount变化时，finalPrice自动更新  
price.value = 200; // finalPrice→160  
discount.value = 0.7; // finalPrice→140  

嵌套场景：computed依赖另一个computed

比如先算“折扣后价格”，再算“满100减20后的价格”：

const price = ref(100);  
const discount = ref(0.8);  
// 第一层computed：折扣后价格  
const discountedPrice = computed(() => price.value * discount.value);  
// 第二层computed：满减后价格（假设满100减20）  
const finalPrice = computed(() => {  
  return discountedPrice.value >= 100  
    ? discountedPrice.value - 20  
    : discountedPrice.value;  
});  
// 当price变化时，discountedPrice先更新，finalPrice再自动更新  
price.value = 150;  
// discountedPrice=150*0.8=120 → finalPrice=120-20=100  

避免在computed里做副作用操作

computed的设计是“纯函数”（可写computed的setter除外），只负责根据依赖计算结果，不能干“副作用”的事——比如发请求、修改其他响应式数据、操作DOM。

看个错误示例：

const count = ref(0);  
const badComputed = computed(() => {  
  count.value++; // 修改count，属于副作用  
  return count.value;  
});  

这种写法会导致循环更新（computed更新触发count变化，count变化又触发computed更新），还会让逻辑混乱，如果要处理副作用，应该用watch或methods。

computed和reactive、ref配合时要注意啥？

Vue 3的响应式核心是reactive（对象式响应式）和ref（值类型响应式），computed和它们配合时，容易踩“响应性丢失”的坑。

问题1：reactive对象解构后，属性失去响应性

比如用reactive定义用户信息：

const user = reactive({  
  name: '张三',  
  age: 18  
});  
// 错误写法：解构后name非响应式  
const { name } = user;  
const userName = computed(() => name + '同学');  
user.name = '李四';  
console.log(userName.value); // 还是“张三同学”，因为name非响应式  

解决方法是用toRefs把reactive对象的属性转成ref：

import { toRefs } from 'vue';  
const { name } = toRefs(user); // name现在是ref对象，保持响应性  
const userName = computed(() => name.value + '同学');  
user.name = '李四';  
console.log(userName.value); // 输出“李四同学”，正常更新  

问题2：ref在computed里的自动解包

用ref定义的变量，模板里会自动解包（不用写.value）；但在组合式API的setup里，访问值需要写.value，不过在computed的回调里，Vue会自动处理.value吗？

看例子：

const count = ref(1);  
const double = computed(() => count * 2); // 没写.count.value？  
console.log(double.value); // 输出2，因为computed内部会自动解包ref  

Vue在computed回调里会自动解包ref的.value，所以可以直接写count而非count.value，但如果是reactive对象里的属性，仍需通过.value或toRefs处理响应性。

用computed常见的坑有哪些？咋避坑？

computed虽好用,但稍不注意就会踩坑，总结几个高频问题和解决方法：

坑1：依赖非响应式数据，导致computed不更新

前面提过,用普通变量当依赖会让computed“聋掉”：

let num = 1;  
const result = computed(() => num * 2);  
num = 2;  
console.log(result.value); // 还是2，不更新  

解决：把普通变量换成ref或reactive包裹的响应式数据。

坑2：在computed里做异步操作或副作用

比如在computed里发请求：

const userInfo = computed(async () => {  
  const res = await fetch('/api/user');  
  return res.data;  
});  

这会导致computed返回Promise,模板渲染出错；且异步操作不属于“纯计算”，逻辑也不清晰。

解决：异步逻辑放到onMounted、watch或methods里，比如用watch监听触发条件，再发请求更新数据。

坑3：可写computed的setter没正确更新依赖

比如做全名拆分时,setter逻辑写错：

const fullName = computed({  
  get() { ... },  
  set(newValue) {  
    // 错误：没更新响应式数据的.value（如果用了ref）  
    firstName = newValue.slice(0, 1); // firstName是ref的话，得写firstName.value  
    lastName = newValue.slice(1);  
  }  
});  

解决：如果firstName和lastName是ref，setter里要通过.value修改：

set(newValue) {  
  firstName.value = newValue.slice(0, 1);  
  lastName.value = newValue.slice(1);  
}  

坑4：computed嵌套过深，调试困难

比如一个computed依赖另一个computed,另一个又依赖第三个，逻辑绕在一起，出问题时很难定位。

解决：把复杂逻辑拆成多个小computed，每个只做单一职责的计算，比如把“折扣计算”“满减计算”“最终价格计算”分成三个computed，逻辑独立，调试时能快速定位。

实际项目中，computed适合哪些场景？

理解了computed的原理和避坑方法,得知道它在项目里到底能解决啥问题，这些场景用computed特别顺手：

场景1：数据格式化

比如后端返回时间戳,前端转成“年-月-日”格式：

const timestamp = ref(1672531200000); // 假设是2023-01-01的时间戳  
const formatDate = computed(() => {  
  return new Date(timestamp.value).toLocaleDateString();  
});  
// 模板里{{ formatDate }} → 显示“2023/1/1”（不同浏览器格式可能不同，可自定义格式化函数）  

场景2：列表过滤/排序

比如待办列表按“已完成”过滤：

const todos = ref([  
  { id: 1, text: '学习Vue', done: false },  
  { id: 2, text: '写代码', done: true }  
]);  
const doneTodos = computed(() => {  
  return todos.value.filter(todo => todo.done);  
});  
// 模板里循环doneTodos，只显示已完成的  

场景3：多数据聚合计算

比如购物车商品的总价（含数量和单价）：

const cartItems = ref([  
  { id: 1, price: 50, quantity: 2 },  
  { id: 2, price: 30, quantity: 1 }  
]);  
const totalPrice = computed(() => {  
  return cartItems.value.reduce((sum, item) => {  
    return sum + item.price * item.quantity;  
  }, 0);  
});  
// 模板里显示{{ totalPrice }} → 50*2 + 30*1 = 130  

场景4：表单验证的联动逻辑

比如注册表单,“密码”和“确认密码”是否一致：

const password = ref('');  
const confirmPassword = ref('');  
const isPasswordMatch = computed(() => {  
  return password.value === confirmPassword.value;  
});  
// 模板里根据isPasswordMatch显示“密码一致”或“密码不一致”  

从基础用法到复杂场景,从语法区别到避坑技巧，computed在Vue 3里的核心逻辑其实围绕“响应式依赖+缓存”展开，掌握这些细节后，你写的代码不仅更简洁，性能也会更优——毕竟谁也不想让用户在页面上等着“重复计算”转圈圈对吧？