说到 Vue 里的 computed 计算属性很多人的第一反应是模板里少写点绕人的逻辑。这个印象没错但 computed 实际承担的工作比这更重它是从已有响应式数据里派生出新数据的纯函数通道决定了模板能看到什么、页面跟着数据怎么变。只要用对了你甚至不需要手动维护一堆中间变量数据源变结果自动跟着变。这篇文章适合所有写 Vue 的人不管你是刚接触 options API 的小白还是已经切换到 script setup Composition API 的开发者。我会把 computed 的原理、常用写法、真实业务场景以及我在项目里踩过的报错和坑一起讲透。所有案例都是我实际写过的不会给你一堆没法落地的概念。1. 你为什么需要一个computed计算属性1.1 模板里写复杂表达式是灾难我先给你看一段我早期写过的真实代码很丑但很多人应该都有共鸣span {{ orders.filter(order order.checked) .reduce((sum, item) sum item.price * item.count, 0) }} /span这行代码能干吗能算购物车里勾选商品的总价。问题在于它塞在模板里一眼看过去根本不知道在算什么。要是担心金额小数点、要不要包邮费再往上叠一个toFixed(2)这行 HTML 就成了一个没有人敢碰的验证码。代码评审的时候别人得凑近屏幕一行一行读改需求的时候你得小心翼翼找括号。这种复杂表达式最要命的不是难看而是不可复用。同样的汇总逻辑你在这个页面写一遍那个弹窗里再写一遍后面规则变了你可能漏改一处。把逻辑抽到 computed 之后模板就变成这样span{{ totalPrice }}/span谁看到都知道这是总价逻辑改了只需动一处。这就是 computed 存在的第一层意义把模板从计算现场变成结果展示。你可能会说那用 methods 不也行吗行但往下看。1.2 computed、methods、watch怎么分工很多人一开始分不清 computed、methods、watch其实你只要记住一句话computed 用于根据现有数据派生新数据methods 用于处理事件和动作watch 用于关注变化后执行副作用。三者的关键差异看这张表方案执行时机缓存典型场景computed依赖的响应式数据变化时重新计算有依赖不变不重算总价、过滤列表、拼接名字、校验状态methods每次渲染都会重新执行无事件处理、按钮点击、表单提交watch监听的数据变化后执行无缓存数据变化后发请求、保存草稿、操作DOM我举个例子fullName firstName lastName这是典型的派生数据。你用 computedfirstName不变时它不会重复执行你用 methods哪怕页面里一个无关的按钮点击触发了 re-render它也会跟着跑一遍。性能差异在小项目里不明显但列表一大、计算一重区别就出来了。那 watch 呢watch 适合做事后动作。比如用户修改了手机号你希望防抖后把修改同步到后台这是副作用不是派生数据。你如果硬要用 watch 去维护一个fullName变量代码会变成数据源 中间变量 监听器三份状态多了一份需要手动同步的东西。computed 恰好把这个同步过程自动化了。一句话能用 computed 表达的关系就不要用 watch 手动搬。这个习惯能帮你少写很多 bug。2. computed背后的响应式原理2.1 依赖收集是怎么发生的很多人用 computed 用得挺溜但一被问它为什么能自动更新就卡壳。理解这块其实不难你可以把它想成一个记账本computed 每次读取响应式数据就在本子上记一笔我用了谁之后某个被记下来的数据变了Vue 就翻出所有相关的 computed通知它们你该重新算了。拿 Vue 3 的代码来说import { ref, computed } from vue const count ref(0) const double computed(() count.value * 2) console.log(double.value) // 0 count.value 1 console.log(double.value) // 2这里的关键是count.value这行读取。在 Vue 3 里ref 和 reactive 都基于 Proxy 实现当你访问count.value时Proxy 的 get 拦截器会记录当前正在运行的计算上下文告诉它double 依赖了 count。这一步就叫依赖收集。到了 Vue 2原理类似只不过底层用的是Object.defineProperty在读取属性时触发 getter 完成收集。所以 Vue 2 里新增、删除属性需要$set而 Vue 3 没有这个烦恼。这也解释了为什么你在 computed 里读一个普通 JS 变量时它不会触发任何更新。比如const now Date.now() const currentTime computed(() now) // 永远不会更新因为now不是响应式数据Vue 根本不知道它什么时候变化。记住computed 只认响应式依赖。2.2 缓存机制和失效是怎么配合的computed 的缓存不是拍脑袋设计出来的。你想模板渲染可能要读好几次同一个计算值如果每次读都重算一遍那实在浪费。所以 Vue 内部给 computed 加了一个脏检查标志第一次读取时认真算一遍算完把结果存起来同时标记当前结果是干净的依赖没变就直接返回缓存依赖变了才重新标脏、重新计算。在 Vue 3 的源码里computed 内部有一个dirty标志和 scheduler。依赖变化后并不会立刻重新求值而是等到你真正访问.value时再算。这就是懒求值。换句话说computed 不是数据一变就马上去算而是数据变了之后有人要读它时我才算。这是一个很重要的认知差异。如果你写了一个永远没被读取的 computed即使它的依赖疯狂变化它也可能一直不执行。这是 Vue 故意的也是缓存带来的性能收益。不过副作用也在这你要是想在 computed 里做数据一变就同步干点什么那会很不靠谱因为执行时机不由你控制。这也是我后面会说别在 computed 里发请求的核心原因之一。3. 从零开始定义一个可用可维护的computed3.1 最常用的getter写法先看 options API 的常见写法export default { data() { return { items: [ { name: 键盘, price: 199, count: 1, checked: true }, { name: 鼠标, price: 89, count: 2, checked: false }, ] } }, computed: { totalPrice() { return this.items .filter(item item.checked) .reduce((sum, item) sum item.price * item.count, 0) } } }再看 Composition API 的等价写法script setup import { ref, computed } from vue const items ref([ { name: 键盘, price: 199, count: 1, checked: true }, { name: 鼠标, price: 89, count: 2, checked: false }, ]) const totalPrice computed(() { return items.value .filter(item item.checked) .reduce((sum, item) sum item.price * item.count, 0) }) /script这两种写法的核心一致getter 是一个函数函数里读取响应式数据然后返回一个新值。你能写成单行就单行逻辑复杂就多行但千万别把整个页面所有计算塞进一个 computed。一个 computed 只做一件事这是最朴素也最有效的维护原则。命名上建议用结果型的名字。比如isValid、totalPrice、filteredList而不是processData、handleList。名字应该描述它是什么而不是它做了什么。毕竟你在模板里看到的是结果不是过程。3.2 什么时候需要setter默认的 computed 是只读的你直接写totalPrice.value 100会得到一个警告或者直接失效。但有些场景确实需要反向赋值。拿全选按钮来说界面上的全选是一个 checkbox它的选中状态应该等于所有子项是否都被选中。这是典型的派生数据可以用 getter 实现。可用户点击 checkbox 时又会把布尔值写回来希望把所有子项都设为选中/未选中。这时候就需要 setter。const allChecked computed({ get() { return items.value.every(item item.checked) }, set(value) { items.value.forEach(item item.checked value) } })注意这里的 setter 不能直接写allChecked.value value。它要做的是把值写回源数据而不是修改自己否则会陷入死循环。你只要记住setter 是给双向绑定场景准备的改的是依赖数据不是存结果。我个人的态度是setter 能不用就不用。大部分情况下读是派生写是业务动作。如果你发现需要写一个 computed 的 setter先停下来想一想是不是可以直接用 checkbox 的 change 事件去更新源数据。全选这种高度统一的场景我建议用 setter其余场景保持只读。3.3 computed能不能传参这是一个高频问题。很多人想在模板里这样用span{{ formatPrice(item.price, item.currency) }}/span如果你把formatPrice定义成 computed那必须让它返回一个函数const formatPrice computed(() { return (price, currency CNY) { if (currency USD) return $ price.toFixed(2) return ¥ price.toFixed(2) } })这样写是可以用的。但你要理解一个重点computed 的缓存只对最外层生效。上面这个例子里缓存的是那个返回出来的函数而不是你每次调用的计算结果。只要任何依赖变化computed 会重新生成一个新的函数同一轮渲染里同一个函数被连续调用多次函数内部的逻辑还是会每次都执行。所以我的建议很简单如果你只是想封装一个格式化函数模板里每次渲染都调用而且计算不重直接用 methods 更直白。如果内部依赖了几个响应式变量创建函数的过程本身有较重计算或者你希望函数生成逻辑稳定才考虑 computed 返回函数。别为了用 computed 而用 computed。4. 真实业务场景中的computed实践4.1 购物车汇总金额这是 computed 最经典的使用场景。一个购物车列表商品有价格、数量、勾选状态页面需要展示已选商品总价。数据源是列表展示值是总价中间没有任何手动的中间变量。const cartItems ref([ { id: 1, name: 机械键盘, price: 399, count: 1, checked: true }, { id: 2, name: 显示器, price: 1299, count: 1, checked: false }, { id: 3, name: USB扩展坞, price: 89, count: 2, checked: true }, ]) const checkedTotal computed(() { return cartItems.value .filter(item item.checked) .reduce((total, item) total item.price * item.count, 0) }) const totalCount computed(() { return cartItems.value .filter(item item.checked) .reduce((total, item) total item.count, 0) })你可能会说不就用 reduce 算个数嘛有什么了不起。真正的价值在于当你修改某个商品的 count或者切换 checkedcheckedTotal会自动重新计算你不需要写任何事件回调去手动更新 total 字段。我见过很多项目在 data 里维护一个total然后每次数量变化都手动加加减减十多个地方要同步一个地方漏了金额就错了。computed 把这个维护成本直接抹掉了。这里有个细节值得注意computed 会追踪你读取的每一层属性。如果你在 computed 里读的是item.checked和item.price那么这两个属性单独变化时computed 也会重新计算。所以不要担心我只 replace 了某个对象的 namecomputed 也跟着算了这种性能问题Vue 的依赖是属性级的不是对象级的。4.2 搜索过滤和排序搜索框、筛选条件、排序方式这三样一组合页面就是一个典型的数据派生场景。比如一个商品列表页用户输入关键字选择分类按价格排序最终展示的列表就是源数据经过处理后的一份派生数据。const keyword ref() const category ref(all) const sortBy ref(priceAsc) const visibleProducts computed(() { let list products.value.filter(product { const matchKeyword product.name.toLowerCase().includes(keyword.value.trim().toLowerCase()) const matchCategory category.value all || product.category category.value return matchKeyword matchCategory }) if (sortBy.value priceAsc) { list [...list].sort((a, b) a.price - b.price) } else if (sortBy.value priceDesc) { list [...list].sort((a, b) b.price - a.price) } return list })这段代码有两个地方容易踩坑。第一toLowerCase()要成对使用。用户输入大写KEYBOARD商品名是小写keyboard如果你只处理一边搜索结果会时灵时不灵。我在早期项目里就因为这个被测试反馈过。第二排序别直接在原数组上做。Array.prototype.sort是会改变原数组的这会让 computed 产生副作用污染源数据。所以上面用了[...list]先浅拷贝再排序。这是我在代码评审里反复强调的规矩computed 里的操作要只读源数据、产出新数据不要碰原数组。搜索过滤用 computed 的好处还在于当分类或关键词不变时即使列表里某个商品的库存字段变化触发了 re-rendervisibleProducts也不会重新跑一遍过滤逻辑。这个缓存优势在数据量上百条之后会很明显。4.3 表单校验和按钮状态表单场景里computed 的价值是把多个字段的校验状态汇总成一个结果。比如注册页用户名不能为空、密码至少 6 位、确认密码要一致这三个条件一票否决都满足才能点提交按钮。const username ref() const password ref() const confirmPassword ref() const usernameValid computed(() username.value.trim().length 3) const passwordValid computed(() password.value.length 6) const confirmValid computed(() password.value confirmPassword.value) const canSubmit computed(() { return usernameValid.value passwordValid.value confirmValid.value })我故意拆成了三个小 computed而不是写一个巨型校验函数。原因有三每个校验规则单独命名模板里可以单独显示错误提示。可复用比如passwordValid还能用于修改密码弹窗。调试方便Devtools 里逐个看哪个校验没过不用在一个大函数里打断点。按钮禁用状态直接:disabled!canSubmit数据源一变化按钮状态跟着变不需要手动维护一个isFormValid标志。至于确认密码这种和另一个字段相关的校验computed 天然适合。因为confirmPassword一变confirmValid就会重算效果和 watch 临时变量一模一样但代码量少一半。4.4 嵌套数据的容错访问在写详情页或者接口返回的数据结构比较深层时模板里最容易出现Cannot read property xxx of undefined。比如{{ user.profile.nickname }}如果profile还没加载出来user.profile 是 undefined模板直接报错。此时 computed 可以做一个带默认值的安全读取const displayName computed(() { return user.value?.profile?.nickname ?? 未登录用户 })这样模板里写{{ displayName }}再深的嵌套也不会炸。可选链和空值合并是 ES2020 的特性现代构建工具基本都支持放心用。这类把容易出错的读取逻辑集中在一个 computed的做法不仅让模板变干净也把容错逻辑集中到了一处。4.5 多个computed之间互相组合computed 里可以读取另一个 computedVue 会把它们自动串成一条依赖链。比如一个订单金额场景const subtotal computed(() products.value.reduce((sum, item) sum item.price * item.count, 0)) const tax computed(() subtotal.value * 0.06) const shipping computed(() subtotal.value 99 ? 0 : 10) const grandTotal computed(() subtotal.value tax.value shipping.value)这里grandTotal依赖tax、shipping而tax又依赖subtotal。任一层数据变了下游自动重算。这比手动维护一个grandTotal变量靠谱得多。不过要注意依赖链别设计成环路。A 依赖 B、B 又依赖 AVue 会直接爆栈后面我会说到这个报错。5. computed报错排查与避坑实录5.1 常见报错速查表我自己在日常开发和帮同事排查问题中遇到过不少 computed 相关的报错。我把最高频的几条整理成一张表你可以直接贴到团队 wiki 里。报错现象常见原因排查方向Cannot read property xxx of undefinedcomputed 访问了未初始化的对象层级通常是接口数据没回来用可选链、空值合并给默认值或等数据 ready 后再访问Maximum call stack size exceededcomputed 出现循环依赖比如读取了自己或 A 依赖 B、B 又依赖 A检查 computed 内部是否出现了环删掉其中一条依赖Computed property is readonly/Write operation failed: computed value is readonly试图给一个只读 computed 赋值给 computed 增加 setter或者直接修改源数据Cannot read property value of undefinedComposition API 里忘了 import或者 setup 里没有返回 computed检查 import 和返回值模板里拼写也要核对computed 值不更新依赖的是普通变量、路由参数、接口返回值而不是响应式数据确认依赖是 ref/reactive/props 或另一个 computed模板里显示[object Object]computed 返回了一个对象直接插到模板里页面要展示具体字段或者在 computed 里返回可显示的字符串5.2 排查技巧和方法遇到 computed 不更新我的排查顺序通常是这样的第一步先确认依赖到底是不是响应式的。最常见的坑是把普通变量写进 computed比如从接口 Promise 里拿到的数据先赋值给了一个普通变量。在 Vue 3 里这个普通变量不会触发更新computed 自然不会重算。换成ref或者放在reactive里就好了。第二步用 Vue Devtools 看 Computed 面板直接能看到每个 computed 当前的值。要是值不对再点进去看看依赖的数据是什么。这个面板比 console.log 直观太多。第三步如果还想现场观察执行时机可以在 computed 里临时塞一行console.log。但你要记住computed 不是每次数据变都会立刻执行。依赖变了可能过了很久才有人读它那时候 console 才打印。所以看到 console 没立刻打出来别急着怀疑没触发先考虑没被读取。第四步最小复现。把一大坨业务代码删到一个十几行的 demo能稳定复现问题再去找原因。这招对排查循环依赖尤其有效因为报错信息只告诉你爆栈了没告诉你在哪个环节爆的。你把依赖链一层层打出来马上能看到环在哪里。5.3 我在项目里踩过的几个坑第一个坑是在 computed 里修改 source 数据。早期写全选按钮我在 setter 里直接items.value items.value.map(item ({ ...item, checked: value }))。表面看能用后来发现其他地方持有旧的对象引用状态对不上。正确做法就是item.checked value原地修改。computed 里的 setter 写赋值给源数据不要写制造一份新数据再替换。第二个坑和数组引用有关。有一个 computed 依赖list.value.length我以为数组里某个对象属性变了它也会更新。结果它没更新。原因在于我读的是list.value.length而不是某个具体对象的属性。Vue 追踪的是你实际读取的依赖length 没变computed 自然不重算。所以如果你的 computed 关心某个对象属性是否变化就老老实实读那个属性不要只读个 length 就想覆盖所有变更。第三个坑在 debug 的时候。我想确认 computed 有没有重算就在 getter 里加了new Date().getTime()然后发现页面怎么每次访问都在变。这个例子比较极端但道理很通用computed 里不要掺入非响应式的时间、随机数、console、DOM 访问。这些东西不会成为依赖只会让你摸不着头脑。第四个坑是 props 解构。在 Vue 3 的script setup里很多新手会写const { userId } props const userInfo computed(() getUserById(userId))然后userId不是响应式变量了computed 自然变成一次性计算。要响应式引用 props得写props.userId或者用toRef(props, userId)。这个坑非常隐蔽因为首次渲染结果是对的后面 props 变了却没反应。6. 从实战里总结的几条使用红线6.1 保持纯派生不产生副作用computed 的 getter 应该是一个纯函数输入依赖数据输出派生结果中途不修改任何其他状态不发请求不改 DOM。你可以把它理解成加工流水线原材料进来成品出来生产线本身不应该改变原材料的性质。一旦在 computed 里写了if (count.value 5) { sendLog() }这看起来很像计数超过 5 自动上报实际会有非常奇怪的行为。因为 computed 执行时机是被读驱动的可能一次渲染读了好几次可能依赖变了但没人读它就完全不上报。这种东西应该放到 watch 里watch 的语义才是变化之后触发动作。6.2 不要在computed里发请求或做异步操作computed 的返回值是同步的。你想在 computed 里 await 一个接口然后返回异步结果从设计上就走不通。有人会写const list computed(() { fetchData().then(res res.list) // 返回的是 Promise不是数据 })这拿到的是一个 Promise 对象不是你要的列表。如果你想要接口数据准备好再展示正确的模式是把接口结果放到响应式 ref 里computed 只负责处理这个 ref请求本身放到 watch 或者事件回调里触发。原因很简单computed 的更新是依赖驱动的你不能期待它去管理异步加载这种生命周期。6.3 不要试图手动刷新computed偶尔会有人问怎么让 computed 强制刷新一遍我的回答通常是你为什么需要刷新computed 是依赖驱动的只要数据源没变它的结果就不应该变。如果你觉得我想让它重新算一下说明真正驱动它变化的那个源数据没有被它依赖或者你根本不应该用 computed。比如你有一个筛选条件在 URL 参数里参数变了页面没更新。正确的做法是把 URL 参数变成响应式源而不是去找强制刷新 computed的 API。只要数据源正确computed 根本不需要你手动刷新。6.4 命名和拆分决定了computed好不好维护写 computed 有一条很简单的心法一个名字对应一个结果一个结果只从一类源数据派生。isLoggedIn、unreadCount、filteredOrders这种名字在模板里读起来就像英文句子的一部分一眼就能看懂。别写dataA、dataB这种名字也别把十几个不相关的派生关系揉进一个 computed。拆也讲究粒度。粒度太粗一个 computed 算二十个字段依赖关系模糊报错没法定位粒度太细页面上出现一堆只有一行逻辑的 computed看起来也很啰嗦。我的习惯是被模板多处引用的、被其他 computed 复用的、逻辑超过两行的单独提出来纯粹一个字段的简单转换比如price * count可以直接写不用强行拆。如果让我用一句话总结使用 computed 的心得我会说把它当作一个响应式的纯计算管道。你在写 getter 时问自己三个问题——读到这里的变化我依赖到了吗返回的结果是稳定且可预测的吗中间有没有偷偷做多余的事三个问题没问题这个 computed 就能睡得安稳。我几乎在每个项目里都把上面的原则贯彻到 code review 里光是把模板里的复杂表达式抽到 computed这一件事就救回过不少可读性濒临崩溃的页面。希望这篇内容能帮你把 computed 用得又稳又顺。