数组与collection转换存在多重运行时开销：隐式转换引发重复堆分配，ienumerable转数组需双重遍历，非泛型接口导致装箱/拆箱及枚举器开销，span.toarray()破坏零分配优势；应优先复用缓冲区或使用只读跨度。
数组和 Collection 之间的转换看似只是类型切换，实则暗藏多层运行时开销。关键不在“能不能转”，而在“谁在转、何时转、怎么转”——尤其当这类操作出现在高频路径（如 UI 刷新、数据管道、序列化中间层）时，GC 压力、内存复制、装箱/拆箱和延迟执行叠加，会迅速放大损耗。
隐式转换触发重复分配
使用 [..collection] 或 collection.ToArray() 看似轻量，但每次调用都会创建新数组。若在循环中反复执行：
- 对
List<int></int>调用ToArray()：内部先分配新数组，再逐个Array.Copy元素，时间复杂度 O(n)，且新数组为短期对象 - 用集合表达式
[..list]初始化新数组：编译器虽优化 IL，但仍需在堆上分配并填充，无法复用已有缓冲区 - 若原 collection 是
IEnumerable<t></t>（如 LINQ 链），ToArray()还需先遍历一次计数、再遍历一次填充，双重开销
泛型集合与非泛型接口的桥接成本
当代码依赖 ICollection 或 IEnumerable 等非泛型接口时，.NET 运行时可能被迫进行：
-
装箱：值类型元素（如
int）被包装为object，写入非泛型集合；后续读取再拆箱，带来 CPU 和 GC 双重负担 -
协变/逆变适配：例如将
List<string></string>传给接受IEnumerable<object></object>的方法，虽语法通过，但底层可能绕过直接引用传递，引入间接层 -
枚举器开销：非泛型
IEnumerator比泛型IEnumerator<t></t>多一次虚方法调用和类型检查
Span 与数组互转的边界陷阱
Span<t></t> 本为栈分配、零分配设计，但与数组交互时易破防：
-
array.AsSpan()安全且免费，仅生成结构体引用 - 但
span.ToArray()必然堆分配新数组，完全抵消 Span 优势 - 更隐蔽的是：把
Span<t></t>传给期望T[]的 API，若该 API 内部调用ToArray()或做反射检查，就会意外触发分配
缓存策略比语法糖更重要
比起追求一行转换，更应关注生命周期管理：
- 对固定内容（如配置项、状态码映射表），直接声明
static readonly T[]，避免每次访问都重建 - 对需频繁转换的中等集合（如每帧 UI 数据），可复用预分配的
ArrayPool<t>.Shared.Rent()</t>缓冲区 - 若目标是只读遍历，优先传
ReadOnlySpan<t></t>或Memory<t></t>，而非构造新 List 或数组
