Vue的computed属性竟然坑了我一把

上周四凌晨两点，我盯着屏幕上诡异的数据更新问题，发现一个本该自动更新的表格死活不响应 ------而这一切的罪魁祸首，竟然是平时最信任的 computed。你可能会想："computed 不是响应式的吗？怎么会出问题？" 今天就用这次血泪教训，给你扒一扒 computed 那些不为人知的"脾气"。

场景复现：为什么我的表格不更新？

项目是一个实时监控系统，前端用 Vue 3 + Composition API。核心逻辑是通过 WebSocket 推送的数据更新表格，而表格数据经过 computed 计算：

javascript 复制代码

const tableData = computed(() => {
  return rawData.value.map(item => ({
    ...item,
    // 关键点：这里用到了外部工具函数
    status: calculateStatus(item.timestamp) 
  }))
})

问题来了：当 rawData 更新时，tableData 有时完全不触发重新计算 。更诡异的是，直接在模板里写 rawData.map(...) 却能正常更新。你猜问题出在哪？

根因：computed 的依赖收集暗坑

computed 的响应式依赖是自动收集 的，但它只认响应式数据内的属性访问。看看我们踩中的几个雷：

外部函数调用 ：calculateStatus 内部如果访问了非响应式变量（比如全局配置），这些依赖不会被 computed 追踪
隐式依赖丢失 ：当 calculateStatus 内部逻辑变更（比如新增了 Date.now() 判断），computed 仍然只认旧的依赖链
嵌套对象陷阱 ：如果 item.timestamp 是嵌套对象且未被 reactive 包裹（比如从普通对象解构而来），其内部变化也不会触发更新

用 Vue 源码中的关键逻辑解释：computed 的 getter 执行时，会通过 effect 建立依赖关系，但只有在这个 getter 执行路径中被实际读取的响应式属性才会被记录。

解法：让依赖显式化

错误写法（隐式依赖）

javascript 复制代码

const config = { threshold: 5 } // 非响应式

function calculateStatus(timestamp) {
  // 这里访问了外部非响应式变量 config
  return timestamp > config.threshold ? 'alarm' : 'normal'
}

正确写法（显式依赖）

javascript 复制代码

const config = ref({ threshold: 5 }) // 改为响应式

function calculateStatus(timestamp) {
  // 通过 .value 触发依赖收集
  return timestamp > config.value.threshold ? 'alarm' : 'normal'
}

// 或者用 computed 封装工具函数
const status = computed(() => calculateStatus(rawTimestamp.value))

性能对比 *：在 10,000 条数据的压力测试下，显式依赖写法比隐式依赖 + 强制更新（用 forceUpdate hack）的方案快 2.3 倍，因为后者会导致不必要的全量重新渲染。

避坑清单：computed 的三大天敌

外部工具函数：函数内若含有非响应式依赖，必须将其参数化或改为响应式对象
动态依赖路径 ：如 computed(() => obj[someKey.value]) 中 someKey 变更不会触发更新
异步操作 ：computed 内若有异步逻辑（比如 await），必须用 watchEffect 替代

最佳实践：把 computed 当纯函数用

现在我强制团队遵守一条铁律：computed 内部应该像纯函数一样工作 。所有依赖必须通过参数或响应式变量显式传入。遇到复杂逻辑时，拆分成多个 computed 比写一个"巨无霸"更可靠。

你可能会问："那什么时候该用 watch 呢？" 我的经验法则：当你有副作用 或需要基于前一个状态计算 时（比如防抖），watch 更合适。而 computed 应该永远只是数据的映射。

最后留个思考题：你在项目中遇到过 computed 失灵的情况吗？是不是也和我一样，曾经以为 "Vue 的响应式系统会魔法"？欢迎在评论区分享你的踩坑故事。