计算属性本身不会导致内存泄漏，但长列表中误用（如为每项定义独立计算属性、在计算中创建未清理闭包或返回大型对象）会引发内存占用高、响应慢及组件无法卸载等问题。

计算属性本身不会直接导致内存泄漏，但它在长列表场景中若使用不当，可能间接引发内存占用过高、响应变慢甚至组件无法卸载的问题。

计算属性的“惰性”本质

Vue 的计算属性是基于响应式依赖进行缓存的：只要依赖未变化，多次访问会直接返回缓存值，不重复执行函数。这本身是内存友好的设计。但问题常出现在以下情况：

• 计算属性内部创建了未清理的闭包或引用（比如监听全局事件、定时器、第三方库实例）
• 计算属性返回了大型对象或深层嵌套结构，且被频繁读取或意外保留引用
• 在 v-for 渲染长列表时，为每一项都定义独立的计算属性（如通过方法调用模拟），实际绕过了计算属性的缓存机制

长列表中计算逻辑的常见误用

比如在表格组件中，为每行数据写一个 computed: { rowStatus() { return this.formatStatus(this.row) } } —— 这在组件实例层面不可行，因为计算属性不能接收参数；若强行在模板中写成 {{ formatStatus(row) }}，就变成了方法调用，每次渲染都执行，还无法缓存。

更糟的是，如果 formatStatus 内部做了 DOM 查询、创建 moment 实例、或调用 lodash.cloneDeep，就会快速累积内存压力。

正确管理方式：分离 + 缓存 + 清理

核心原则是：把计算逻辑从响应式上下文中“摘出来”，交给可控的缓存策略和生命周期管理。

• 用 memoize 工具缓存纯函数：对格式化、过滤、转换类逻辑，用 lodash.memoize 或自定义简易缓存（如 Map + JSON.stringify key）封装，避免重复计算
• 用 computed 处理“列表级”派生状态：例如 filteredItems、visibleRange，而不是为每个 item 单独计算
• 避免在计算属性中产生副作用：不绑定事件、不启动定时器、不修改外部状态；如有必要，改用 watch + onBeforeUnmount 显式清理
• 长列表启用虚拟滚动：只渲染可视区域的数据，自然减少计算属性触发次数和内存驻留项

检查与验证的小技巧

打开 Chrome DevTools 的 Memory 面板，录制组件挂载 → 滚动长列表 → 卸载组件的全过程，查看堆快照中是否有残留的 Vue 组件实例、闭包或大型数组。重点关注 Detached DOM tree 和 Closure 类型对象是否异常增长。

也可以在 computed 函数开头加 console.count('rowStatus called')，观察调用频次是否符合预期——若远超列表长度，说明缓存失效或被错误触发。