Rust for-in循环遍历非可复制类型Vec是否触发内存重分配？

先看你给出的代码：

let strings: Vec<String> = something;
for s in strings {
    // 使用`s`
}

这里的核心是：遍历操作直接消耗了整个strings Vec，你的几个误解都源于对这个过程的认知偏差，下面逐个解答：

每次迭代后Vec对象的状态是怎样的？ #

当你写出for s in strings时，Rust会自动把strings转换成IntoIter类型的迭代器——这个迭代器会接管原Vec的内存缓冲区和所有元素的所有权，而原strings变量此时会进入已被消耗的状态，你无法再对它进行任何操作（编译器会直接报错）。

不存在“Vec变短”的情况，因为原Vec已经不再拥有那些元素了，迭代器才是当前元素的所有者。你假设的[ None, "world", "final string" ]或者[ "world", "final string" ]都不符合实际情况，原Vec在循环开始后就已经失效了。

为什么实际并未发生重新分配？ #

IntoIter迭代器的实现非常高效：它会维护两个指针（或者说偏移量），一个指向当前要取出的元素，另一个指向缓冲区的末尾。每次迭代只是把当前指针指向的元素移动到循环变量s中，然后把指针向后偏移一个元素的位置——整个过程完全不需要移动缓冲区里的其他元素，也不需要修改内存布局，自然不会触发任何内存重新分配。

你提到的C++ deque的偏移量思路，Rust的IntoIter其实用了类似的逻辑，但它是直接在原Vec的内存上操作，不需要额外的结构。

遍历包含非可复制对象的Vec会很慢吗？ #

完全不会。这种遍历的效率和遍历Vec<i32>这类可复制类型几乎没有区别：

• 没有内存分配开销，迭代器直接复用原Vec的内存；
• 没有元素的内存拷贝（只是所有权的转移，对于String来说，只是把它的三个字段（指针、长度、容量）拷贝了一下，实际的字符串数据根本没动）；
• 迭代过程是O(n)时间复杂度，和遍历Copy类型的Vec完全一致。

举个例子，下面的代码里原Vec在循环后无法使用，验证了它被消耗的状态：

let strings = vec!["hello".to_string(), "world".to_string(), "final string".to_string()];
for s in strings {
    println!("{}", s);
}
// 取消注释下面这行会触发编译错误：value borrowed here after move
// println!("{:?}", strings);

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