如何避免数组与集合交互导致的性能损耗问题？

本文共计800个文字，预计阅读时间需要4分钟。

数组与Collection之间的转换看似只是类型切换，实则隐藏多层运行时开销。关键不在于能否转换，而在于谁在转换、何时转换以及如何转换——这类操作频繁出现在高频路径（如UI刷新、数据管道、序列化中间层）时，GC压力、内存复制、装箱/拆箱和延迟执行栈的叠加，会迅速放大损耗。

隐式转换触发重复分配

使用 [..collection] 或 collection.ToArray() 看似轻量，但每次调用都会创建新数组。若在循环中反复执行：

• 对 List<int> 调用 ToArray()：内部先分配新数组，再逐个 Array.Copy 元素，时间复杂度 O(n)，且新数组为短期对象
• 用集合表达式 [..list] 初始化新数组：编译器虽优化 IL，但仍需在堆上分配并填充，无法复用已有缓冲区
• 若原 collection 是 IEnumerable<T>（如 LINQ 链），ToArray() 还需先遍历一次计数、再遍历一次填充，双重开销

泛型集合与非泛型接口的桥接成本

当代码依赖 ICollection 或 IEnumerable 等非泛型接口时，.NET 运行时可能被迫进行：

• 装箱：值类型元素（如 int）被包装为 object，写入非泛型集合；后续读取再拆箱，带来 CPU 和 GC 双重负担
• 协变/逆变适配：例如将 List<string> 传给接受 IEnumerable<object> 的方法，虽语法通过，但底层可能绕过直接引用传递，引入间接层
• 枚举器开销：非泛型 IEnumerator 比泛型 IEnumerator<T> 多一次虚方法调用和类型检查

Span<T> 与数组互转的边界陷阱

Span<T> 本为栈分配、零分配设计，但与数组交互时易破防：

• array.AsSpan() 安全且免费，仅生成结构体引用
• 但 span.ToArray() 必然堆分配新数组，完全抵消 Span 优势
• 更隐蔽的是：把 Span<T> 传给期望 T[] 的 API，若该 API 内部调用 ToArray() 或做反射检查，就会意外触发分配

缓存策略比语法糖更重要

比起追求一行转换，更应关注生命周期管理：

• 对固定内容（如配置项、状态码映射表），直接声明 static readonly T[]，避免每次访问都重建
• 对需频繁转换的中等集合（如每帧 UI 数据），可复用预分配的 ArrayPool<T>.Shared.Rent() 缓冲区
• 若目标是只读遍历，优先传 ReadOnlySpan<T> 或 Memory<T>，而非构造新 List 或数组