计算属性名本身不触发GC，但动态生成大量字符串会频繁填满第0代堆，间接导致GC加剧；应通过性能分析确认根源，用缓存、预定义键、批量处理和数值键等优化减少分配。
计算属性名本身不会直接导致垃圾回收（GC）频繁触发，真正的问题在于：动态生成大量字符串（如用模板字面量、拼接或 Symbol 生成的键名），会持续分配短生命周期对象，快速填满第 0 代堆，从而间接引发更频繁的 GC 周期——尤其在高吞吐异步场景（如实时数据映射、高频状态更新）中尤为明显。
识别是否真由计算属性名引起
先确认问题根源，避免误判：
- 用 PerfView 或 dotnet-trace 捕获 GC 事件，重点关注
GC/AllocationTick和GC/Start，观察 Gen 0 回收频率是否与属性名生成逻辑强相关 - 检查内存快照中是否存在大量
System.String实例，且其分配栈指向类似obj[`key_${i}`]或Symbol.for('dynamic-' + id)的代码段 - 对比禁用该逻辑后 Gen 0 回收次数是否显著下降（例如从每秒 20+ 次降至 2–3 次）
用缓存代替重复生成
对可预测、有限范围的计算名，优先复用已有字符串或 Symbol：
- 使用静态字典缓存常见组合：
private static readonly ConcurrentDictionary _keyCache = new();，调用前先 TryGetValue - 对枚举类或固定前缀场景，改用预定义常量或
ReadOnlySpan拼接（避免堆分配） - 若必须用 Symbol，统一用
Symbol.for("prefix." + key)而非Symbol()，确保相同键名复用同一 Symbol 实例
减少字符串分配频次
把“每次访问都算一次”变成“按需批量算一次”：
- 将高频计算属性名的逻辑上移到初始化或配置阶段，运行时只查表，不拼接
- 在异步流水线中，合并多个待处理项，用单次循环生成全部键名，而非每个 item 单独构造
- 对纯数字索引场景（如
`item-${id}`），考虑改用int或long作为字典键，完全绕过字符串分配
调整 GC 行为辅助过渡
仅作临时缓解，不能替代代码优化：
- 在关键路径开始前，设
GCSettings.LatencyMode = GCLatencyMode.LowLatency，降低 GC 中断影响（注意：仅限短时关键区，用完即恢复） - 避免在热路径中调用
GC.Collect()—— 它会强制阻塞并打乱 GC 自适应节奏，反而加剧抖动 - 确认未启用
