Vue.js computed 怎么用？这些关键问题帮你理清

terry 2小时前阅读数 20 #SEO

文章标签 js computed

computed 到底是什么？

你可以把 computed 理解成“基于其他响应式数据计算出来的衍生属性”，打个比方：做购物车时，“商品总价”不是直接存在 data 里的，而是由“商品单价”和“购买数量”这两个数据推导而来，这时候用 computed，Vue 会自动跟踪它依赖的数据源（比如单价、数量），只有这些数据源变化时，计算逻辑才会重新执行；如果数据源没变化，直接复用上次的计算结果（也就是“缓存”）。

看个简单代码例子：

<template>
  <div>
    <p>单价：{{ price }}</p>
    <p>数量：{{ count }}</p>
    <p>总价：{{ totalPrice }}</p>
    <button @click="count++">增加数量</button>
  </div>
</template>
<script>
export default {
  data() {
    return {
      price: 50,
      count: 2
    }
  },
  computed: {
    totalPrice() {
      return this.price * this.count; // 依赖 price 和 count
    }
  }
}
</script>

这里 totalPrice 就是计算属性，点击按钮让 count 增加时，totalPrice 会自动重新计算；但如果 price 和 count 都不变，不管模板里渲染多少次 totalPrice，它只会计算一次，之后直接拿缓存结果——这就是 computed 提升性能的关键。

computed 和 methods 有啥区别？

很多新手会疑惑：“既然 methods 里写函数也能算出总价，为啥还要用 computed？” 核心区别在“是否缓存”和“执行时机”这两点：

执行时机不同：
methods 里的函数，每次页面渲染、事件触发，甚至父组件传值变化时都会重新执行，比如模板里写 {{ getTotalPrice() }}，哪怕 price 和 count 没变化，只要组件有任何更新（比如其他 data 变了），这个函数都会重新跑一遍。

但 computed 是“懒执行”的——只有依赖的数据源（price、count）变化时，才会重新计算；如果依赖没变化，直接复用缓存结果。
缓存逻辑不同：
假设做一个 Todo 列表，需要显示“未完成任务数量”，用 computed 的话，只有 Todo 列表里的任务状态变化时，才会重新计算数量；用 methods 的话，哪怕 Todo 列表没变化，每次组件渲染（比如切换路由再切回来），方法都会重新执行一次，Todo 数据很多，频繁执行 methods 里的遍历逻辑，性能差距会非常明显。
使用场景不同：
methods 更适合“触发动作”（比如点击按钮发起请求、批量修改数据），或者“不需要缓存”的临时计算；computed 适合“基于已有数据做衍生计算”，且这个计算逻辑会被多次调用的场景。

computed 的依赖是怎么被 Vue 自动跟踪的？

Vue 的响应式系统是“依赖收集 + 发布订阅”模式，computed 能自动感知依赖变化，背后靠这套机制：

当 Vue 解析 computed 里的 totalPrice 时，会分析它的 getter 函数（也就是 return this.price * this.count 这行），在 getter 执行过程中，Vue 会“暗中收集”所有被访问的响应式数据（this.price 和 this.count，因为它们在 data 里，是响应式的），这些被收集的响应式数据，totalPrice 的依赖项。

一旦某个依赖项（price）变化，Vue 就会标记 totalPrice 为“需要重新计算”，等到下一次页面渲染时，才会真正执行 getter 函数，更新计算结果。

举个反例辅助理解：computed 里的逻辑没访问响应式数据，会怎样？

computed: {
  randomNum() {
    return Math.random(); // Math.random() 不是响应式数据
  }
}

这时 randomNum 没有依赖项，所以它只会在组件初始化时计算一次，之后不管怎么操作，都不会再更新——因为没有响应式数据能触发它重新计算。

computed 能处理异步逻辑吗？

直接说结论：computed 默认不适合处理异步，因为 computed 的核心是“缓存 + 同步返回值”，它需要在 getter 里立即返回计算结果给模板渲染，但异步操作（比如调接口、定时器）是“延迟拿到结果”的，这会让 computed 的缓存机制失效，甚至导致逻辑混乱。

如果业务确实需要“基于异步数据做计算”，分两种情况处理：

情况 1：异步数据是外部传入的（比如接口返回的列表）
优先用 watch 监听异步数据变化，再在回调里处理计算逻辑，比如要根据接口返回的用户列表，计算“VIP 用户数量”：
```
<script>
export default {
  data() { return { userList: [] } },
  watch: {
    userList(newList) {
      this.vipCount = newList.filter(user => user.isVip).length;
    }
  }
}
</script>
```
情况 2：必须在 computed 里写异步（极少数场景）
可以结合 Promise 或第三方库（vue-async-computed），但写法很绕——因为模板要处理 Promise 的状态（pending/fulfilled/rejected），举个不太推荐的例子：
```
computed: {
  async userInfo() {
    const res = await axios.get('/user');
    return res.data;
  }
}
```
模板里得这么写：{{ userInfo.then(data => data.name) }}，既麻烦又容易出错，所以优先用 watch 处理异步场景，更符合 Vue 设计逻辑。

哪些真实场景一定要用 computed？

computed 不是“可有可无”的语法糖，很多场景不用它，代码会又乱又慢，分享几个典型场景：

场景 1：数据格式化

后端返回的时间是时间戳（如 1678923456789），前端要显示“YYYY - MM - DD”格式，用 computed 把时间戳转成日期字符串，且只在时间戳变化时重新计算：

computed: {
  formatTime() {
    return dayjs(this.timestamp).format('YYYY-MM-DD');
  }
}

场景 2：复杂逻辑的组合判断

做“全选”checkbox 时，它的选中状态依赖所有子选项是否都被选中，如果不用 computed，每次子选项变化都要手动更新全选状态，极易漏逻辑：

computed: {
  isAllChecked() {
    return this.todoList.every(todo => todo.checked);
  }
}

当任何一个 todo 的 checked 状态变化时，isAllChecked 会自动更新，模板里直接绑定 isAllChecked 即可，无需手动维护。

场景 3：表单验证逻辑

注册页面中，“确认密码”是否和“密码”一致的验证逻辑，适合丢进 computed，只要其中一个输入框变化，就重新验证：

computed: {
  isPwdMatch() {
    return this.password === this.confirmPwd;
  }
}

模板里可根据 isPwdMatch 显示“密码一致”或“密码不一致”的提示。

computed 里能修改数据吗？

默认情况下，computed 的函数是getter（只负责“获取”计算后的值），这时候直接修改其他数据容易造成循环依赖或不可预测的更新。

但如果业务需要“通过计算属性修改数据”，可以给 computed 配置setter，比如做一个“全名”的计算属性，支持双向绑定：

<template>
  <div>
    <input v-model="fullName" placeholder="输入全名">
    <p>姓：{{ firstName }}</p>
    <p>名：{{ lastName }}</p>
  </div>
</template>
<script>
export default {
  data() {
    return {
      firstName: '张',
      lastName: '三'
    }
  },
  computed: {
    fullName: {
      // getter：获取全名
      get() {
        return this.firstName + this.lastName;
      },
      // setter：修改全名时，拆分给 firstName 和 lastName
      set(newValue) {
        this.firstName = newValue.slice(0, 1);
        this.lastName = newValue.slice(1);
      }
    }
  }
}
</script>

当用户在输入框修改 fullName 时，setter 会被触发，把输入的字符串拆分成 firstName 和 lastName，这种场景虽少，但遇到“计算属性双向绑定”需求时，setter 很实用。

computed 的核心优势与避坑点

核心优势：缓存机制提升性能；自动跟踪依赖，减少手动维护成本；让模板与复杂逻辑解耦（模板不用写一堆计算逻辑，全丢 computed 里）。
避坑要点：别在 computed 里写异步逻辑（优先用 watch）；注意依赖必须是响应式数据（非响应式数据不会触发更新）；setter 要谨慎使用（防止循环更新）。

理解 computed 的关键，是记住它“为衍生数据而生”——让那些由其他数据计算而来的逻辑，变得更高效、更可控，多写几个小 Demo（比如购物车、Todo 列表、表单验证）,就能彻底掌握它的用法～