计算属性名本身不触发gc，真正原因是频繁创建短生命周期字符串/对象导致新生代内存快速填满；应预构建映射表、用数组索引、缓存动态key、复用对象而非重建、冻结常量、复用正则，并通过devtools定位高频分配点。
计算属性名本身不会直接导致垃圾回收（GC）频繁触发，真正的问题在于：为生成这些属性名而反复创建字符串、对象字面量、临时闭包或动态键值对时，产生了大量短生命周期对象，加速了新生代内存填满，从而间接促使引擎更频繁执行 GC。
避免在循环或高频函数中拼接属性名
每次用 obj[`${prefix}${i}`] = value 或 { [key]: value } 都会新建字符串和/或对象。尤其在 for 循环、渲染函数、响应式依赖收集等场景中，极易形成批量小对象堆积。
- 预先构建好固定属性名的映射表，复用对象而非动态生成，例如：
const KEYS = Object.freeze({ item_0: 'item_0', item_1: 'item_1' }); - 若 key 模式固定且数量可控，改用数组索引代替字符串键，如
items[i] = value，完全绕过属性名解析开销 - 对必须动态生成的 key，缓存已生成结果（如用 Map 存储
keyTemplate → finalKey），避免重复计算
慎用计算属性名创建新对象字面量
像 return { [getDynamicKey()]: data } 这类写法，在每次调用时都新建一个对象，即使结构相同也无法复用。这类对象很快进入新生代，被快速回收，但频次高就会拖慢整体节奏。
- 优先复用已有对象，通过赋值更新字段，而非重建整个对象
- 需要多组配置时，用不可变方式预定义常量对象，例如：
const CONFIGS = { list: { key: 'listItems', type: 'array' }, detail: { key: 'detailData', type: 'object' } }; - 若需运行时派生，考虑用
Object.assign(target, { [key]: value })复用 target，减少分配
警惕模板字符串与正则中的隐式字符串创建
看似轻量的 `user-${id}-profile` 或 new RegExp(`^${keyword}`)，每次执行都会生成新字符串实例。在搜索、过滤、响应式 getter 中高频出现时，字符串对象会成批滞留在堆中。
- 对稳定 pattern 的字符串，提取为顶层常量或冻结对象字段
- 正则表达式尽量复用实例，避免每次 new；可配合
RegExp.prototype.test的 lastIndex 机制做状态管理 - 使用
String.raw或字符数组拼接替代嵌套模板（仅当性能敏感且 key 模式简单时）
监控与定位真实压力点
不要假设“计算属性名”是罪魁——它只是表象。真正该检查的是：谁在频繁调用？返回值是否被立刻丢弃？是否捕获了大作用域？
- 用 Chrome DevTools 的 Memory > Allocation instrumentation on timeline 录制操作，观察哪些函数分配最多字符串/对象
- 重点关注 getter、computed、watch 回调、事件处理器中带
[]或Object.keys()+ 动态访问的代码段 - 检查是否无意中把整个响应式对象、DOM 节点甚至大型数据结构闭包进计算逻辑里，导致引用无法释放
