为何ICollection<T>在C# 12集合表达式语法中被特殊处理？

C# 12的集合表达式语法在不同目标类型下的IL转换逻辑差异，核心是语义一致性优先的设计原则，而非单纯看接口实现或性能。

先回顾你观察到的转换差异：
多数场景下，集合表达式会根据目标类型做直观转换：

// 原始代码
Collection<int> a = [5, 2];
IEnumerable<int> b = [5, 2];
IReadOnlyList<int> c = [5, 2];

被转换为：

// 编译器生成代码
Collection<int> a = new Collection<int> { 5, 2 };
IEnumerable<int> b = new <>z__ReadOnlyArray<int>(new int[2] { 5, 2 });
IReadOnlyList<int> c = new <>z__ReadOnlyArray<int>(new int[2] { 5, 2 });

但当目标类型是ICollection<T>时，转换逻辑完全不同（调试模式）：

// 原始代码
ICollection<int> d = [5, 2];

被转换为：

// 编译器生成代码
List<int> list = new List<int>();
CollectionsMarshal.SetCount(list, 2);
Span<int> span = CollectionsMarshal.AsSpan(list);
int num = 0;
span[num] = 5;
num++;
span[num] = 2;
num++;
ICollection<int> d = list;

为什么不直接用<>z__ReadOnlyArray？ #

虽然<>z__ReadOnlyArray<T>确实实现了ICollection<T>，但编译器选择List<T>的核心原因有两点：

1. 接口契约的语义匹配
   ICollection<T>的接口契约不仅包含只读操作，还定义了可修改操作（Add、Remove、Clear等）。而<>z__ReadOnlyArray<T>是一个只读包装类，所有修改方法都会抛出NotSupportedException。如果直接将它赋值给ICollection<T>，调用者基于接口契约会预期集合是可修改的，这会导致意外的运行时异常，违背了接口的语义承诺。

而List<T>是ICollection<T>的完整实现，所有修改方法都能正常工作，完全符合ICollection<T>的语义预期。

2. 性能与语义的权衡
   你测试发现小元素场景下<>z__ReadOnlyArray<T>更快，大元素场景下List<T>更优，但编译器的转换逻辑是基于目标类型的语义而非元素数量。对于ICollection<T>这种隐含可修改预期的类型，编译器优先保证语义正确性，其次才考虑性能——而且List<T>的构造方式已经通过CollectionsMarshal做了极致优化（直接设置内部数组长度、用Span赋值），避免了常规List.Add的扩容检查，性能表现并不差。

总结 #

集合表达式的转换逻辑是语义驱动的：

• 对于只读导向的接口（IEnumerable<T>、IReadOnlyList<T>），优先使用轻量的只读包装类<>z__ReadOnlyArray<T>，兼顾性能和只读语义；
• 对于包含可修改契约的接口（ICollection<T>），选择完全实现该契约的可变集合类型List<T>，保证接口语义的一致性，避免运行时异常。

内容的提问来源于stack exchange，提问作者Arseni Mourzenko