为何C#中仍保留数组，而实际开发常用List<T>？

• 底层实现依赖：List<T>本身就是基于数组实现的——它内部维护了一个数组来存储元素，扩容时会重新分配更大的数组并复制元素。除此之外，.NET里很多核心类型（比如string的字符存储）、LINQ方法的底层逻辑，都依赖数组作为基础存储结构。不懂数组，就没法真正搞懂List<T>这类高级集合的工作原理。

• 性能优势场景：当你需要一个长度固定的集合时，数组的性能比List<T>更优。数组是连续内存块，缓存命中率更高，访问元素的开销更小；而且不需要List<T>那层封装的额外开销，比如容量管理、方法调用的间接成本。在处理大规模数据计算、高性能要求的场景中，数组是更合适的选择。

• API与兼容性要求：很多.NET的原生API、旧代码或者跨平台交互场景（比如P/Invoke调用C++库）都依赖数组。最典型的就是程序入口的static void Main(string[] args)，必须用数组接收命令行参数。还有一些老的框架方法，返回值或参数类型就是数组，你没法完全避开它。

• 语义明确性：数组的语义比List<T>更清晰——当你声明int[] scores = new int[10];时，所有人都知道这是一个固定长度的集合；而List<int>默认是动态可扩容的，哪怕你手动限制了元素数量，也不如数组的语义直接。在需要强调“固定长度”的场景下，数组是更合适的选择。

• 基础学习价值：数组是集合编程的基础概念，几乎所有编程语言都有数组。掌握数组的内存模型、访问方式，能帮你更好地理解集合的核心逻辑——比如为什么List<T>的扩容会有性能损耗，什么时候该手动设置Capacity优化性能。跳过数组直接学List<T>，相当于没搞懂底层原理就用工具，遇到问题很难排查。

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