Rust中bytes与chars迭代器nth方法性能差异及next_back()优化原理问询

嘿，这真是个有意思的性能对比发现！让我一步步给你拆解背后的逻辑：

先明确你的测试场景与结果 #

方案1：bytes().nth(i)反向遍历

pub fn test(word1: String) {
    for i in (0..word1.len()).rev() {
        word1.bytes().nth(i);
    }
}

运行耗时：约820微秒（当word1.len() = 42551时）

方案2：chars().nth(i)反向遍历

pub fn test(word1: String) {
    for i in (0..word1.len()).rev() {
        word1.chars().nth(i);
    }
}

运行耗时：约17.5秒（相同字符串长度下）

方案3：chars()迭代器+next_back()反向遍历

let mut word1_chars = word1.chars();

for i in (0..word1.len()).rev() {
    word1_chars.next_back()
}

运行耗时：约600微秒（相同字符串长度下）

为什么bytes().nth(i)比chars().nth(i)快这么多？ #

核心原因在于Rust中String的底层存储和两个迭代器的实现逻辑：

• bytes()迭代器直接操作String底层的字节数组：String本质是UTF-8编码的字节序列，bytes()会直接遍历这个数组的每一个元素。nth(i)在这里可以直接通过索引定位到数组的第i个字节，时间复杂度是O(1)。哪怕循环里每次重新创建bytes()迭代器，定位的成本依然极低。
• chars()迭代器是遍历UTF-8字符：UTF-8中一个字符可能占1-4个字节，chars()需要逐个解析字节来识别完整的字符。而nth(i)的逻辑是从迭代器起始位置开始，逐个跳过i个字符直到找到目标。更糟的是你在循环每次迭代都重新创建chars()迭代器——这意味着每次调用nth(i)都要从字符串开头重新遍历，直到数到第i个字符。对于长度为n的字符串，每次nth(i)的时间是O(i)，整个循环总时间复杂度是O(n²)，这就是4万多长度的字符串会慢到17秒的关键原因。

为什么next_back()的性能反而比bytes()还高？ #

当你把chars()迭代器存到变量里再调用next_back()时，迭代器会内部维护当前的遍历位置：

• next_back()是从迭代器的尾部往前逐个取字符，它不需要每次从头开始遍历，而是直接从当前记录的尾部位置反向解析前一个UTF-8字符。整个循环下来只需要遍历字符串一次，时间复杂度是O(n)。
• 而且Rust标准库对Chars迭代器的next_back()做了专门优化，它会利用UTF-8的编码规则快速定位前一个字符的起始位置，再加上你只创建了一次迭代器（不像bytes()方案每次循环都新建），所以最终性能甚至超过了bytes()的实现。

希望这些解释能帮你理清背后的逻辑！

备注：内容来源于stack exchange，提问作者SebastiaanTheCoder