枚举及其子类型在栈/堆存储下的行为与所有权问题

这个问题其实戳中了Rust所有权系统里一个很关键的点——Copy类型和非Copy类型在模式匹配里的行为差异，咱们一步步拆解清楚：

1. 原代码为啥能正常运行？ #

你原来的Answer::No(i32)里，i32是实现了Copy trait的基础类型。当你写match qna.answer的时候，Rust会自动复制一份i32的值出来用于匹配——相当于把qna.answer里的数字拷贝了一份到栈上，原对象里的内容完全没动。因为qna是引用（&QnA），但你只是复制了它里面的一个Copy类型值，并没有尝试移动整个answer的所有权，所以编译器完全没意见。

2. 改成String为啥就报错了？ #

String是非Copy类型，它的底层是堆上的字节数组，本身只在栈上存了指针、长度和容量。当你尝试直接match qna.answer时，Rust会尝试把这个String从QnA结构体里移动出来——但问题是qna是一个引用，你只有借用权，没有所有权，根本没资格移动它背后的对象！这就是编译器报错“无法移动引用背后的内容”的核心原因。

3. 两种解决思路，本质都是“不移动，只借用” #

思路一：匹配枚举的引用

直接把匹配目标改成&qna.answer，这样你匹配的是整个Answer枚举的引用，而不是枚举本身：

fn check(qna: &QnA) {
    match &qna.answer {
        Answer::Yes => println!("positive"),
        Answer::No(why) => println!("negative cause {}", why),
    }
}

这里的why其实是&String类型，不过Rust会自动解引用（Deref coercion）让你直接用{}打印，非常贴心。

思路二：用ref关键字在模式里借用

如果你不想改匹配目标，也可以在模式里加ref，告诉Rust“我只是想借用这个String，不要移动它”：

fn check(qna: &QnA) {
    match qna.answer {
        Answer::Yes => println!("positive"),
        Answer::No(ref why) => println!("negative cause {}", why),
    }
}

这个写法和思路一本质是一样的，都是创建了对String的借用，避免了所有权移动。

关于结构体的影响 #

其实结构体在这里只是个“容器”，核心问题和它关系不大——哪怕你直接拿一个&Answer来匹配，里面的非Copy类型照样会出同样的错。结构体只是把枚举包装了一层，让你需要通过qna.answer来访问枚举而已。

总结一下核心规律 #

• 栈上的基本类型（i32、bool、char等）大多是Copy类型，匹配时会自动复制，不涉及所有权移动；
• 堆分配的类型（String、Vec、自定义结构体等）是非Copy类型，匹配引用指向的这类对象时，必须用引用匹配或者ref关键字来避免移动所有权。

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