计算属性本身不生成微任务或触发GC，问题源于其getter中隐式递归、闭包持有大对象或响应式依赖失控；需检查异步调用、避免修改响应式数据、精简依赖范围、合理缓存与防抖。
计算属性名本身不会生成微任务，也不会直接触发垃圾回收。问题实质是：计算属性内部逻辑不当（比如隐式递归、闭包持有大对象、响应式依赖失控），导致其副作用函数反复执行或长期驻留，进而引发微任务堆积和 GC 压力。
检查计算属性是否隐式触发微任务循环
Vue 的计算属性（computed）本身是同步求值的，但若其 getter 中主动调用 queueMicrotask、Promise.resolve().then 或返回一个未 await 的 Promise，就可能意外引入微任务。更隐蔽的是：getter 里调用了某个封装函数，而该函数内部无条件再次触发了响应式更新（例如修改了另一个 ref，又触发了另一个 computed 重新求值），形成“响应式链式自调用”。
- 逐个审查计算属性 getter，确认没有直接或间接调用异步调度 API
- 特别留意是否在 getter 中修改了响应式数据（如
someRef.value = ...），这会触发依赖更新，可能引发新一轮计算属性求值 - 使用 Vue Devtools 的“Reactivity”面板观察某次状态变更后，哪些 computed 被连续触发，是否存在非预期的连环求值
避免计算属性闭包捕获冗余大对象
每个计算属性的 getter 函数在创建时会形成闭包，如果它引用了大型数组、未释放的 DOM 节点、JSON 解析结果或整个组件实例，这些对象就会被长期持住——即使计算属性没重求值，它们也无法被 GC 回收。
- 在 getter 内部只解构提取真正需要的字段，例如：
const { id, name } = props.user，而非直接使用props.user - 对大型临时数据做显式清理，比如
const rawData = JSON.parse(str); const result = processData(rawData); rawData = null - 避免在 computed 中直接访问
this.$refs或this.$el，改用onMounted+ref显式管理生命周期
用缓存与防抖替代高频重计算
当计算属性依赖的数据变化频繁（如输入框实时搜索、滚动位置监听），每次变更都触发同步求值虽不产生微任务，但会加重主线程负担，并间接延长微任务队列清空时间（因主线程被占满，GC 无法插入空闲周期）。
- 对非关键路径的计算属性，改用
watch+ref手动缓存，并加setTimeout或requestIdleCallback延迟更新 - 依赖输入类响应式数据时，先用
debounce过滤抖动，再触发计算逻辑，例如：const debouncedQuery = useDebounce(query, 300)，然后基于debouncedQuery定义 computed - 对纯派生数据（如格式化、过滤），优先使用方法调用（
formatName(item)）而非 computed，把执行时机交给模板渲染阶段，避免提前占用资源
精简响应式依赖范围
计算属性会自动收集其 getter 中读取的所有响应式依赖。若 getter 冗长、嵌套深或误读了本不该关心的响应式字段（比如读取了整个 store.state 或未过滤的 props 对象），会导致依赖树膨胀，每次相关数据变更都会强制重求值，加剧内存压力。
- 确保计算属性只读取最小必要集，例如用
toRefs(props)后再解构，避免无意中追踪整个 props 对象 - 对来自 Pinia/Vuex 的状态，使用
storeToRefs并仅解构所需字段；避免在 computed 中直接访问store.xxx深层属性链 - 对大型数组或对象，考虑用
shallowRef或markRaw标记非响应式部分，防止 Vue 为其建立 Proxy 和依赖追踪
