应避免在高频场景中滥用不可变集合：ImmutableArray 修改开销大，ImmutableList 随机访问慢于 List，ImmutableHashSet 适合多线程共享或需历史版本的场景；优先复用 Builder、预设容量、避免短生命周期 Builder，并警惕旧版本引用导致的冗余分配与 GC 压力。
ImmutableArray 的内存分配开销比 T[] 高得多
每次调用 ImmutableArray<t>.Add()</t> 或 ImmutableArray<t>.SetItem()</t> 都会创建新数组对象，底层触发 Array.Copy() 或 Array.Resize()。这不是“修改原数组”，而是构造全新副本——哪怕只改一个元素，也要复制整个底层数组。
实操建议：
- 避免在 tight loop（如每帧更新、高频事件处理）中反复调用
Add()或Builder.Add()后再ToImmutable()；改用ImmutableArray.CreateBuilder<t>()</t>累积，最后一次性转出 - 若已知大小，优先用
ImmutableArray.Create<t>(params T[] items)</t>或ImmutableArray<t>.Empty.AddRange(items)</t>，避免 Builder 内部多次扩容 -
ImmutableArray<t></t>本身是 struct，但其内部持有的T[]是 heap 对象；大量小数组（如ImmutableArray<int></int>长度为 1–5）会导致堆碎片加剧
ImmutableList 查找和索引访问比 List 慢 2–5 倍
ImmutableList<t></t> 底层是平衡树（AVL tree），不是数组。这意味着 list[i] 不是 O(1)，而是 O(log n)；list.Contains(x) 也是 O(log n)，而非 List<t>.Contains()</t> 的 O(n) ——但常数因子更大，实际性能更差。
常见错误现象：
- 把
ImmutableList<t></t>当作List<t></t>替代品用于频繁随机访问场景（如 UI 列表渲染、物理引擎粒子索引） - 误以为
ImmutableList<t>.ToImmutableArray()</t>是零拷贝转换——它仍要遍历整棵树并分配新数组 - 未注意
ImmutableList<t>.Value</t>属性已废弃，直接访问list[i]就是树遍历
何时该用 ImmutableHashSet 而不是 HashSet
只有当你需要「历史版本保留」或「多线程安全共享」且不希望加锁时，ImmutableHashSet<t></t> 才有存在价值。它的插入/查找平均仍是 O(1)，但哈希桶结构是不可变的 trie，每次变更都重建部分 trie 节点，带来额外指针跳转和 GC 压力。
使用场景对比：
- 单线程、写少读多 → 用
HashSet<t></t>+ReadOnlySet<t></t>包装更轻量 - 需记录“上一帧集合状态”供回滚 →
ImmutableHashSet<t></t>可直接保存引用，无需深拷贝 - 跨 Task 共享集合且拒绝锁 →
ImmutableHashSet<t></t>避免ConcurrentDictionary的复杂同步逻辑 - 注意：
ImmutableHashSet<t>.Union()</t>和Intersect()并非就地合并，而是生成新实例；若链式调用多次，务必用var result = set1.ToBuilder().UnionWith(set2).UnionWith(set3).ToImmutable();
Builder 模式不是银弹，过度使用反而更慢
ImmutableArray.CreateBuilder<t>()</t>、ImmutableList.ToBuilder() 等确实能减少中间对象，但它们本身是 class，每次调用 ToImmutable() 仍要执行一次完整结构重建（如数组拷贝、树重平衡）。如果 builder 生命周期短、复用率低，开销可能比直接用可变集合还高。
性能关键点：
- builder 复用很重要：不要在方法内 new builder → 操作 → ToImmutable() → return；应作为字段或池化对象复用
-
ImmutableArray.CreateBuilder<t>(initialCapacity)</t>显式指定容量，避免 builder 内部数组多次 resize - 对纯追加场景，
List<t></t>+ 最后一次ToArray()或AsReadOnly()往往比 builder + immutable 更快 - 调试时留意 GC 第 0 代回收频率——
Immutable*类型高频分配极易引发 GC Storm
真正影响性能的往往不是“不可变”这个概念，而是你是否在不该持久化的路径上保留了旧版本引用。比如缓存了一个 ImmutableList<t></t> 实例却从未复用，又在下一帧新建另一个——这时你付出的是双倍内存+双倍构建时间，而收益为零。
