computed 是 Vue 中用于声明式派生状态的响应式工具，基于惰性求值、依赖追踪与缓存复用机制，仅在依赖变化时重新计算，适用于列表过滤、格式化、权限判断等场景。
computed 是 Vue 中最常用也最容易被误解的响应式工具之一。它不只是“自动更新的属性”，背后有一套精巧的依赖收集与缓存机制。用好 computed，能显著减少冗余计算、避免副作用、提升可读性，甚至成为业务逻辑分层的关键支点。
缓存原理：为什么 computed 只在依赖变化时才重新求值？
computed 的核心是惰性求值 + 依赖追踪 + 缓存复用。Vue 在初始化时并不会立即执行 getter 函数，而是在首次访问该 computed 属性时才执行，并将结果缓存；后续访问直接返回缓存值，直到其依赖的响应式数据（如 data、props、其他 computed）发生变化，触发重新求值和缓存更新。
关键细节：
- 依赖必须是被 Vue 响应式系统接管的数据（ref、reactive、data 中的属性），普通变量或函数调用不会被追踪
- getter 内部不能有副作用（比如发请求、改 state），否则缓存会导致行为不可预期
- 如果 computed 返回的是对象或数组，其内部属性变更不会触发重新求值——因为 computed 缓存的是整个返回值引用，不是深层响应式
对比 methods 和 watch：什么场景下必须用 computed？
很多人把“需要计算”就写成 methods，但这是典型误用。methods 每次调用都执行，不缓存；watch 适合执行异步或开销大的副作用；computed 则专为派生状态（derived state）而生——即从已有响应式数据中声明式地推导出新值。
立即学习“前端免费学习笔记（深入）”；
典型适用场景：
- 列表过滤：如
filteredList = list.filter(item => item.status === activeStatus) - 格式化展示：如
fullName = firstName + ' ' + lastName - 权限判断：如
canEdit = user.role === 'admin' || ownPost - 组合多个 prop 或 store 状态生成 UI 状态：如
isFormValid = name && email && !loading
反例：在模板里反复调用带参数的 methods（{{ formatTime(item.time, 'YYYY-MM-DD') }}），应改用 computed + setup 里的辅助函数，或用 memoized 工具函数。
进阶技巧：用 computed 实现业务逻辑解耦与重构
当组件逻辑变复杂，把计算逻辑散落在 template 或 methods 里会迅速失控。computed 可作为“逻辑胶水”，把原始数据 → 业务语义 → UI 状态层层抽象。
例如订单页重构：
- 原始写法：template 里一堆三元表达式判断
statusText、showPayBtn、isCancelable - 重构后：
• orderState（computed）→ 聚合 order.status、payment.status、time 等，输出标准化状态对象
• uiConfig（computed）→ 基于 orderState 返回按钮文案、颜色、是否禁用等 UI 参数
• 模板只绑定 uiConfig.payButton，彻底剥离业务规则
这种模式让业务规则集中在少数几个 computed 中，测试友好、复用性强，后续加新状态只需扩展 orderState，不影响视图层。
避坑指南：常见错误与优化建议
以下问题高频出现，且不易排查：
-
响应式丢失：对 computed 返回的对象做
Object.assign或解构赋值后修改，原 computed 不更新 —— 应用toRefs或保持响应式引用 - 无限循环：在 setter 中修改了 getter 的依赖项（如 setter 里改了 this.count，而 getter 用了 this.count）—— setter 应只用于同步反向推导，避免副作用
- 过度嵌套：A computed 依赖 B，B 依赖 C，C 依赖 D……导致调试困难 —— 建议单个 computed 职责单一，复杂链路拆成命名清晰的中间 computed
-
性能错觉：以为用了 computed 就一定快 —— 若 getter 内部做了深克隆、大数组遍历、正则全局匹配等重操作，仍可能卡顿；必要时用
useMemo类工具或防抖策略
