凌晨三点，Vue 开发者还在排查 computed 属性导致的页面卡顿。原本应该缓存的计算结果，因为一个数组的 push 操作触发了全量重算，项目上线时间被迫延后。这起事故源于对响应式系统依赖追踪的误判。

computed 依赖追踪在深层嵌套对象上容易断裂

Vue 的 computed 属性依赖于响应式系统的依赖收集机制。当 computed 函数首次执行时，Vue 会追踪其中读取的所有响应式数据，把它们记录为依赖。只有当这些依赖发生变化时，computed 才会重新计算，否则直接返回缓存值。

在实际项目中，开发者经常遇到深层嵌套对象的情况。比如一个用户配置对象包含多层属性，如果 computed 只读取了顶层引用，而后续修改的是嵌套属性，依赖追踪就可能断裂。信号中提到的凌晨排查经历，正是因为对象深层属性变更后，computed 没有正确捕捉到变化，导致缓存一直使用旧值，页面显示错误。

这种断裂的根源在于 Vue 2 的 Object.defineProperty 对新增和删除属性的监听局限，以及 Vue 3 虽然改用 Proxy 但仍需开发者显式访问才能建立依赖。开发者常常以为只要把整个对象放进 computed 就能自动追踪所有子属性，实际上必须在 getter 中真正读取那些字段才能建立有效依赖。

凌晨三点的 debug 过程显示，当把嵌套路径完整写出如 config.theme.colors.primary 时，依赖才被正确收集。否则即使对象被修改，computed 也不会失效。这直接导致了页面状态不一致，开发团队花了几个小时才定位到依赖链断裂的位置。

实际开发中，推荐使用 toRefs 或在 computed 里显式解构需要监听的字段，避免隐式依赖。否则上线前临时改动一个深层配置，就可能引发看似莫名的缓存失效。这也是许多中型 Vue 项目反复踩坑的原因之一。

直接修改 computed 内部引用的可变数据会破坏缓存

computed 的核心价值在于缓存。一旦 getter 返回的是同一个引用，Vue 就会跳过后续计算。但如果 computed 内部引用了一个可变数组或对象，而外部代码直接对这个数组执行 push、splice 等操作，缓存就会被意外破坏。

信号里的案例正是如此。开发者在 computed 中返回了一个过滤后的列表数组，结果业务代码直接在这个返回数组上调用了 push。新元素虽然加进去了，但 computed 本身认为依赖没有变化，下次读取仍然返回旧缓存，导致页面显示缺失数据。直到强制刷新或依赖的其他响应式数据变更，才触发重算。

这种风险与其他节不同，它不是依赖追踪失效，而是主动破坏了 Vue 对返回值的不可变假设。Vue 无法自动感知返回对象内部的 mutation，因此 push 操作不会触发 computed 的重新计算，却改变了实际展示结果。

解决办法是让 computed 始终返回新数组，比如使用展开运算符或 slice() 复制。虽有一定性能代价，但在中型列表场景下收益远大于调试成本。项目中一旦出现「改了数据但 computed 不更新」的情况，优先检查是否直接 mutation 了 computed 返回的可变值。

这个陷阱在团队协作时特别危险。新来的开发者看到 computed 返回数组，很容易直接操作它而不去了解背后的缓存逻辑，最终把加班时间消耗在追查这种隐蔽 bug 上。

把异步或副作用塞进 computed 会引发状态混乱

computed 的设计要求其 getter 必须是纯函数，不能产生副作用，也不能包含异步操作。这条规则被违反后，状态一致性立刻崩溃。

如果在 computed 里发起网络请求或调用会改变外部状态的函数，那么每次访问 computed 都可能产生不同结果，缓存也失去意义。更严重的是，异步操作完成后更新其他响应式数据，又可能触发新一轮 computed 计算，形成难以预测的循环。

信号中提到的凌晨卡顿案例里，就有人尝试在 computed 里混入 async/await 来获取额外数据。结果是页面渲染期间 Promise 处于 pending 状态，computed 返回 undefined，随后数据到达又触发重渲染，整个过程既不缓存也不稳定。

调试这类问题特别痛苦，因为副作用的执行时机与渲染周期绑定，错误堆栈往往指向 Vue 内部调度器而不是业务代码。保持 computed 纯净，把异步逻辑移到 watch 或生命周期钩子里，是维持状态可预测性的唯一办法。

中文开发者常因「想少写一个 watch」而把副作用塞进 computed，最终付出更多调试时间。记住：computed 只负责计算，副作用交给 watch 或 setup 中的 effect。

大型列表或复杂计算不做节流会卡死主线程

当 computed 处理大型列表或进行复杂数值计算时，每次依赖轻微变化都触发重算，会直接占用主线程导致页面卡顿。信号中的项目正是因为一个包含上千条记录的 computed 过滤器，在数组每次 push 时都全量执行，导致浏览器帧率暴跌。

量化来看，一个对 5000 条数据做 map+filter 的 computed，在现代笔记本上单次执行可能消耗 15-30ms。如果每秒触发 10 次，轻松吃掉 300ms 主线程时间，用户会明显感到卡顿。项目上线前压测阶段才暴露这个问题，迫使团队紧急优化。

性能陷阱的具体表现包括：computed 依赖的数组长度变化、过滤条件变化、或者任何上游响应式数据变更，都会无条件重跑整个计算。Vue 虽然做了缓存，但缓存粒度是整个返回值，只要依赖变了就全部重算，没有内置的增量更新能力。

实际项目中，推荐对大型列表使用虚拟滚动组件结合手动节流，或者把复杂计算拆成多个细粒度 computed 让 Vue 分别缓存。另一个办法是把计算逻辑移到 Web Worker，但这会增加代码复杂度。

信号里的经历表明，开发阶段如果不做性能预算，很容易在上线前夜才发现 computed 把主线程卡死。及早用 performance 面板记录 computed 执行时间，能避免很多加班。

用 Vue Devtools 快速定位 computed 依赖链

Vue Devtools 是排查 computed 问题的利器。它能实时展示每个 computed 的依赖项、缓存状态和触发次数。

在组件面板中展开 computed 属性，Devtools 会列出当前值、是否命中缓存以及依赖的响应式路径。凌晨排查时，开发者正是通过查看依赖链，发现某个深层嵌套属性没有出现在列表里，才确认是依赖追踪断裂。

另一个实用功能是 Timeline 录制。开启后可以记录页面操作期间所有 computed 的重新计算事件，清楚看到哪个 push 操作触发了哪些 computed 重跑，以及每次重跑耗时。信号中的卡顿场景通过 Timeline 很快定位到问题 computed 执行了 27 次。

调试方法还包括在依赖数组上手动加一个测试 ref，观察 computed 是否随它更新。通过 Devtools 的「依赖」视图能直观看到 computed 与 data、props、其他 computed 之间的关系网，帮助开发者理清复杂的依赖链。

对中文开发者来说，熟练使用 Devtools 的 computed 面板能把定位时间从几小时缩短到几分钟。建议在开发环境中保持 Devtools 常开，尤其在处理包含多层计算的表单或列表页面时。

何时该把 computed 替换成 watchEffect 或 watch

不是所有场景都适合 computed。当需要执行副作用、处理异步、或者计算结果不需要被模板直接消费时，watch 和 watchEffect 往往是更好选择。

判断标准很简单：如果目的是根据数据变化「做点事情」而不是「得到一个值」，就该用 watch。信号中的项目后来把几个涉及异步校验的逻辑从 computed 迁移到 watchEffect，状态混乱立刻消失，代码也更清晰。

性能对比上，watch 可以设置 deep 和 immediate 等选项，灵活控制执行时机，而 computed 总是同步且立即求值。在大型计算场景下，watch 配合防抖能显著降低主线程压力。

日常开发建议是：模板中直接绑定的值优先用 computed，保证缓存；需要响应数据变化执行操作的场景用 watch；需要立即执行且自动清理的副作用用 watchEffect。这样的分工能避免 computed 被滥用，也减少了类似凌晨三点加班排查的情况。

团队代码审查时，可以把「computed 里是否包含副作用或异步」作为检查项，帮助新手快速建立正确认知。

参考来源