Rust 性能陷阱：那些看起来很优雅但很慢的写法（上）

这篇文章是偏实操的，将带你看看那些看起来很优雅、实际上在悄悄拖慢程序的 Rust 写法，搭配示例代码、原因剖析、以及优化方法，帮你避坑，写出既简洁又高效的 Rust 代码。

过度使用 Iterator 链

Rust 的迭代器（Iterator）是函数式编程的核心特性之一，很多开发者都喜欢用它写出简洁流畅的链式调用，比如这样：

rust 复制代码

let result: Vec<_> = data.iter()
    .filter(|x| x.is_valid())
    .map(|x| process(x))
    .collect();

一行链式调用，就完成了过滤、处理和收集三个操作，代码简洁、逻辑清晰，看起来非常优雅，也是很多 Rust 教程里推荐的写法。

但是，在大多数简单场景下，Rust 的编译器（rustc）会优化掉迭代器链的中间层，让它的性能和手写 for 循环几乎一致。但是如何有闭包逻辑过于复杂、迭代器调用链过长、泛型嵌套过多等情况，可能会导致优化实效。

对于性能敏感的热路径（hot path），手写 for 循环虽然看起来不够优雅，但性能更可控、更稳定，也能避免编译器优化失效的风险。

热路径指代的是频繁执行、影响整体性能的核心代码，这里应该优先用 for 循环，而非炫技式的使用 Iterator 链。对于非热路径的代码用 Iterator 链提升可读性完全没问题。

频繁使用 clone()

Rust 的所有权机制是其内存安全的核心，但这也让很多初学者养成了遇事不绝就 clone。

rust 复制代码

let s2 = s1.clone();

但是 clone 是有代价的：对于 String、Vec 等堆分配类型，clone 是深拷贝，这不仅要复制栈上的元数据，还要复制堆上的实际内容，开销巨大。而且频繁 clone 就会频繁触发内存分配器（allocator）的调用，增加内存管理开销。

所以解决 clone 滥用就是尽量避免不必要的拷贝，优先通过所有权流转或借用解决：

如果不需要修改数据，直接使用借用（&T），避免拷贝；
如果需要只读时借用，修改时拷贝，使用 Cow（Copy-On-Write），避免不必要的深拷贝；
明确所有权流转，通过 move 语义转移所有权，而非拷贝。

rust 复制代码

// 直接借用，无需 clone
fn process(s: &str) { ... }

// 使用 Cow，避免不必要的拷贝
use std::borrow::Cow;
fn get_data() -> Cow<'static, str> {
    let static_str = "hello";
    if some_condition() {
        Cow::Borrowed(static_str) // 只读，借用
    } else {
        Cow::Owned(static_str.to_string()) // 需要修改，才拷贝
    }
}

滥用 Vec::push 导致频繁扩容

Vec 是 Rust 中最常用的动态数组，很多人习惯用 Vec::new() 初始化，然后不断用 push() 添加元素，比如这样：

rust 复制代码

let mut v = Vec::new();
for i in 0..100000 {
    v.push(i);
}

这段代码其实是有问题的，这会导致频繁的的内存扩容，也是常见的性能陷阱。

Vec 的底层是连续的内存空间，当调用 push() 时，如果当前内存空间已满，Vec 会执行以下操作：

分配一块更大的内存（通常是当前容量的 2 倍）；
将原有的所有元素复制到新的内存空间；
释放原来的内存空间。

对于示例中循环100000次的 push 操作，这一过程中必然发生多次的内存扩容，每一次扩容都会带来内存复制的开销，不仅耗时，还会导致性能抖动（突然的卡顿）。

解决这个问题也很简单：如果大致知道 Vec 的规模，提前预分配容量。用 Vec::with_capacity(n) 初始化 Vec，直接分配足够的内存空间，避免后续的扩容操作：

rust 复制代码

let mut v = Vec::with_capacity(100000); // 预分配足够容量
for i in 0..100000 {
    v.push(i);
}

错误使用 HashMap

HashMap 是 Rust 中常用的哈希表实现，很多人习惯不考虑场景，直接无脑使用标准库里的 HashMap：

rust 复制代码

use std::collections::HashMap;

let mut map = HashMap::new();

但实际上，Rust 标准库的 HashMap 在性能敏感场景，比如高频读写、大数据量存储，是不够用的，会成为性能开销瓶颈。HashMap 默认使用 SipHash 哈希算法，这种算法的优势是抗哈希碰撞攻击，能有效防止 DoS 攻击，安全性很高，但代价是速度不够快。

如果你使用的场景不需要抵御哈希碰撞攻击，比如内部服务、非公开接口，可以选择更高效的哈希表实现。这里最为推荐的是使用 Rust 团队维护的 rustc-hash crate 里的 FxHashMap，它采用更简单的哈希算法，速度更快，内存占用更低，但安全性较弱。

rust 复制代码

use rustc_hash::FxHashMap;

let mut map: FxHashMap<u32, u32> = FxHashMap::default();
map.insert(22, 44);

String 的拼接问题

字符串拼接是日常开发中很常见的操作，很多人习惯用 += 或 push_str 循环拼接字符串：

rust 复制代码

let mut s = String::new();
for item in items {
    s += &item;
}

这段代码看起来简洁，但背后的时间复杂度可能悄悄退化为 O(n²)，数据量越大，性能越差。这里的问题其实和 Vec 类似，String 也是基于连续内存的动态字符串，每次用 += 拼接时，如果当前内存空间不足，就会触发 realloc（重新分配内存）进行扩容，并将原有的字符串内容全部拷贝到新的内存空间。

所以字符串拼接性能问题也和使用 Vec 一样，预分配容量：

rust 复制代码

// 先获取所有字符串的总长度，用于预分配容量
let estimated_size = items.iter().map(|s| s.len()).sum();
let mut s = String::with_capacity(estimated_size);
for item in items {
    s.push_str(item);
}

除此之外，还可以使用 join() 方法，join() 会自动预分配合适的容量，效率比循环 += 高得多。但实际开发中，我更推荐的还是预分配容量，它的性能最好。

预告

这是《Rust 性能陷阱：那些看起来很优雅但很慢的写法》的上半部分，只讲了其中的五节，剩余的部分将来下半部分讲完。