Rust中为什么无法创建非常量长度的原生数组？

首先明确核心前提：Rust 里的原生数组 [T; N] 是栈分配的固定大小类型，而 Vec<T> 是堆分配的动态大小容器，二者的内存模型从根上就不一样，设计限制完全来自内存安全和类型系统的底层规则，不是随意做的约束。

1. 栈内存的分配规则不支持运行时确定长度 #

程序运行时的栈内存是严格按函数调用栈帧管理的：每个函数的栈帧需要多大空间，是编译器在编译阶段就计算好的，进入函数时直接把栈指针移动固定偏移，退出时再移回去，整个过程没有额外的运行时内存管理开销。
如果允许创建长度在运行时才确定的栈上数组，编译器根本没法提前算出栈帧的预留大小，会直接破坏栈内存的布局确定性。再加上栈本身的空间非常小（默认通常只有1-8MB），运行时传入的长度一旦超出栈剩余空间，就会直接触发栈溢出，这类问题在编译期完全无法排查，和Rust的内存安全目标相悖。

2. 原生数组的长度是类型的一部分，必须编译期确定 #

Rust 是强静态类型语言，所有变量的类型必须在编译期完全确定，默认都实现 Sized trait（即编译期可知类型的内存大小）。
对原生数组 [T; N] 来说，长度 N 本身就是类型签名的一部分：[usize; 3] 和 [usize; 5] 是完全不同的两个类型，二者的内存大小、方法实现、trait 匹配规则都不一样。如果 N 是运行时才能拿到的值，就意味着这个变量的类型在编译期是不确定的，整个静态类型检查、泛型推导、内存布局优化的逻辑都没法成立。

3. 现有安全方案已经完全覆盖动态长度需求 #

Rust 没有原生支持运行时长度数组（也就是常说的VLA），本质是因为这类特性天生带不可控的安全风险，且已经有更稳妥的替代方案，完全没必要在核心语法里加有缺陷的设计：

• 需要动态扩容、任意长度的连续内存：直接用 Vec<T>，它在栈上只存固定大小的胖指针（数据指针、当前长度、预留容量，共3个usize长度），实际数据存在堆上，长度可以任意动态调整，完全符合编译期类型检查规则
• 只需要临时读取/操作一段连续内存，不管它是数组还是Vec：用切片 &[T] / &mut [T]，切片本身也是固定大小的胖指针（数据指针+长度），长度信息存在指针的元数据里，不影响类型的确定性，就是示例代码里do_something参数用的类型
• 确实需要在栈上分配运行时确定长度的小数组：生态里有经过安全校验的封装实现，会在运行时做栈空间检查，不会触发未定义行为

对应示例代码如下，可以直观体现二者的差异：

fn do_something(a: &mut [usize]) {
    for i in 0..a.len() {
        println!("{}", a[i]);
    }
    println!();
}

pub fn main() {
    let capacity: usize = 5;
    // Vec在栈上的大小固定，实际数据存在堆，长度可以运行时动态变化
    let mut v: Vec<usize> = Vec::with_capacity(capacity);
    for i in 0..capacity {
        v.push(i);
    }
    do_something(v.as_mut_slice());
    v.push(11);
    do_something(v.as_mut_slice());

    const CONST_CAPACITY: usize = 5;
    // 原生数组长度是常量，整个数组存在栈上，编译期就能确定总大小
    let mut arr: [usize; CONST_CAPACITY] = [0; CONST_CAPACITY];
    do_something(&mut arr);
}

补充说明：C语言支持的VLA（变长数组）已经被大量实践证明是安全坑点，极易触发栈溢出、未定义行为，C标准后来也把它从必选特性改成了可选特性，Rust从设计之初就避开了这类已知的缺陷设计。

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