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>实例却从未复用，又在下一帧新建另一个——这时你付出的是双倍内存+双倍构建时间，而收益为零。
