vue 3 computed死循环源于getter中意外修改依赖数据，形成“读→写→再读”闭环；需通过console.trace、performance面板、reactivity依赖图定位反向依赖，严禁在getter中执行写操作，副作用应交由watch处理。
Vue 3 中 computed 死循环不是 Vue 出了问题，而是计算属性在求值过程中意外修改了自己依赖的数据，触发“读→写→再读”无限链路。排查关键在于快速定位谁在读的时候偷偷写了。
看控制台报错和堆栈线索
遇到 Maximum recursive updates exceeded 报错时，别跳过堆栈：
- 在疑似出问题的 computed getter 第一行加
console.trace('xxx computed')，观察是否连续打印同一行 - 打开 Chrome DevTools → Performance 面板 → 录制一次操作 → 查找密集重复的 “Vue” 标记或
queueWatcher → flushSchedulerQueue → updateComponent调用闭环 - 若使用 Vue Devtools，进入 “Reactivity” 面板，找到该 computed，检查它的依赖图里是否出现了自己——这是典型的反向依赖闭环
逐行检查 getter 中的“写操作”
computed 只应读取、返回，不能修改任何响应式源。重点扫描以下写法：
-
count.value++、this.list.push(item)、user.profile.age = 25 - 看似安全的解构赋值：
const { name } = this.user; this.user.name = name + '!'—— 后半句已触发 setter - 对数组排序：
props.checkdate.sort()，尤其多个 computed 共享同一数组并都排序时极易互触 - 用
JSON.parse(JSON.stringify(obj))深拷贝后又赋回原响应式对象，造成重赋值+响应式断裂
区分 computed 和 watch 的职责
如果你的需求是“某值变了，就发请求/改另一个状态/存 localStorage”，这根本不是 computed 的活：
- ❌ 错误：在 computed 里调
api.fetch()或this.flag = true - ✅ 正确：用
watch监听源数据变化，加守卫（如if (newVal !== oldVal)）后再执行副作用；需要缓存结果，额外配一个ref存起来 - 特别注意
watchEffect：它自动收集依赖，但若内部有写操作，同样会触发循环，务必加条件判断或暂停追踪（onInvalidate或临时pause）
临时验证与隔离手段
不确定哪段代码惹的祸？用这几招快速验证：
- 把可疑的 computed getter 内容全注释掉，看报错是否消失
- 对疑似被修改的响应式字段临时加
Object.freeze()，若循环停止，说明它确实被意外写了 - 高频更新场景下，把同步写操作改成
nextTick(() => { ... })可打断当前循环链（仅用于定位，不是修复） - 检查模板中是否用了
{{ doSomething() }}这类方法调用，且方法内部有 push、赋值等操作
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
