Vue computed 里修改依赖值为什么会造成循环更新

Vue 的 computed 适合描述“由已有状态计算出来的值”，不适合在 getter 里修改它读取的依赖。比如 getter 读取 count.value，又在同一次计算中执行 count.value++，就把“读取依赖”和“写回依赖”连成了闭环：依赖变化会让 computed 失效，重新计算又再次修改依赖，组件就可能重复更新或出现循环更新警告。

先用最小示例还原循环更新

问题通常不是“computed 不能修改任何东西”这么简单，而是 getter 修改了自己依赖的状态。下面的示例把循环压缩成一个数字：

import { ref, computed } from 'vue'

const count = ref(0)

const doubled = computed(() => {
  // 读取 count 后又写回 count，形成 computed 的自依赖闭环
  count.value += 1
  return count.value * 2
})

console.log(doubled.value)

第一次访问 doubled.value 时，Vue 会收集 count 这个依赖；getter 里面的自增又触发了同一响应式源。即使某次运行没有立刻报错，这个写法也会让结果依赖访问顺序，缓存失去清晰的语义，后续组件更新更难判断。

循环的根因是派生值反向改变来源

computed 的缓存建立在响应式依赖上：只有依赖变化，它才需要重新求值。这个机制隐含了一个方向：源状态 → computed → 模板或其他消费者。getter 如果反过来改变源状态，就变成了“源状态 → computed → 源状态”，循环的根并不在模板，而在依赖图的方向被破坏。

还要留意对象场景。下面虽然没有直接给 items 重新赋值，但 sort() 会就地改动原数组，同样属于 getter 副作用：

const items = ref([{ name: 'B' }, { name: 'A' }])

const sortedItems = computed(() => {
  // sort 会原地修改 items.value，不要在 computed getter 中这样做
  return items.value.sort((a, b) => a.name.localeCompare(b.name))
})

如果只想得到排序结果，应复制后再排序；复制后的数组是新的派生快照，不会污染源数据：

const sortedItems = computed(() => {
  // 复制容器后排序，保持源数组只读
  return [...items.value].sort((a, b) => a.name.localeCompare(b.name))
})

把写操作移出 computed，恢复单向状态流

最常见的修复方式是让 computed 只计算，把变更放在用户动作对应的方法里。例如筛选列表时，filteredItems 只依赖筛选条件和源列表；清空条件则由事件处理器修改 keyword：

如果需求是“源状态变化后做副作用”，例如保存筛选条件、发起请求或同步到外部系统，就使用 watch。监听源值并回写另一个明确不同的目标，依然要防止目标变化再次触发同一监听：

import { ref, watch } from 'vue'

const keyword = ref('')
const requestState = ref('idle')

watch(keyword, async (value) => {
  // watch 用来承接状态变化后的副作用，而不是计算展示值
  if (!value.trim()) {
    requestState.value = 'idle'
    return
  }
  requestState.value = 'loading'
})

writable computed 不是循环修复开关

Vue 支持同时提供 getter 和 setter 的 writable computed，适合把一个可编辑的展示值拆回多个源字段。例如全名输入框可以在 setter 中分别更新姓和名。但这和在 getter 中偷偷写依赖完全不同：写入路径必须由调用方明确触发，getter 仍应保持只读。

可以用下面的表快速判断该把逻辑放在哪里：

发布前检查这几个依赖边界

• getter 内是否出现赋值、++、--、push、sort、reverse 或异步请求？
• 返回数组或对象时，是否误用了会就地修改源数据的方法？
• 需要副作用的逻辑是否已经移到事件处理器或 watch？
• watch 的回调是否又修改了它直接监听的同一个值？
• writable computed 的写入是否只在 setter 中发生，并且有明确调用路径？

常见问题

computed 里调用 push 一定会循环吗？

不一定每次都立刻形成可见循环，但它会在 getter 中改变响应式源，破坏派生值的纯计算约定。应改为复制后操作，或把追加动作放到事件方法中。

computed 可以修改返回对象的字段吗？

如果该对象来自响应式源，修改字段仍可能污染源状态。把 computed 返回值当作临时快照处理，需要编辑时复制一份草稿对象。

什么时候用 watch 替代 computed？

当目标是请求、日志、DOM 或外部存储等副作用时用 watch；如果只是把输入转换成另一个显示值，继续用纯 computed。

记住一条简单规则：computed 负责回答“值是什么”，事件方法和 watch 负责处理“状态要怎么变”。把这两个职责拆开，循环更新通常就能在依赖图层面消失。