数组初始化快于默认List，预设容量后性能持平；数组直接分配连续内存，比new List<int>()快约40%，但预设容量后差距消失。
没有绝对“哪个性能好”，只有“在什么场景下谁更合适”——选错类型，性能可能差3–5倍。
初始化和填充：数组快，但List预设容量后几乎持平
数组直接分配连续内存，初始化速度约比默认构造的 List<T> 快40%。但这是指 new List<int>() 这种没给容量的情况。一旦你预设了容量，差距就消失了：
int size = 1_000_000; // 数组：最快 int[] array = new int[size]; for (int i = 0; i < size; i++) array[i] = i; // List：加 capacity 后，性能逼近数组 List<int> list = new List<int>(size); // 关键！避免内部多次扩容 for (int i = 0; i < size; i++) list.Add(i);
- 不设
capacity：100万次Add可能触发 20+ 次扩容复制，拖慢整体速度 - 设了
capacity：内存一次到位，Add 变成纯赋值，开销极小 - 如果数据量完全未知（比如流式读取），数组根本不适用，别硬扛
随机访问（如 for 循环遍历、取第N个元素）：两者基本一样快
因为 List<T> 底层就是数组，list[i] 最终也是指针偏移访问。JIT 优化后，差异通常在纳秒级，可忽略。
- 但数组有更强的缓存局部性，超大集合（如图像像素处理）中，连续访问时数组仍略优
-
List<T>多一层边界检查和方法调用，不过现代 .NET 已高度内联，实际影响微乎其微 - 别为了这点差异把业务逻辑改成数组——可读性和维护成本更重要
插入/删除中间元素：List赢麻了，数组根本没法比
在索引 50 万处插入一个元素：array 必须新建数组 + 复制前后所有元素（O(n)）；而 List<T> 内部自动处理位移，实测快 3–5 倍。
-
array插入 = 手动Array.Copy+ 新建数组 → 容易写错、GC 压力大 -
List<T>.Insert(500000, value)一行搞定，语义清晰 - 如果真要高频中间插入/删除，且长度固定，考虑
LinkedList<T>；但注意它牺牲了随机访问能力
什么时候必须用数组？什么时候该无脑选List？
真实项目里，90% 的“容器选择”其实早有答案：
- 用
int[]/byte[]：图像处理、序列化缓冲区、高性能计算、与非托管代码交互（P/Invoke）、Span<T> 源头 - 用
List<T>：业务列表（用户订单、搜索结果）、需要 Add/Remove/Find/Sort 的场景、DTO 层集合属性、EF Core 查询结果 - 别纠结“性能更好”的幻觉——如果瓶颈真在容器访问上，大概率是算法或IO问题，不是换数组就能解决的
最容易被忽略的一点：不是“数组 vs List”，而是“是否做了容量预估”“是否用了 Span<T> 或 Memory<T> 替代”“是否在热路径里反复创建新集合”。这些细节，比选类型重要得多。
