Rust中HashMap查找逻辑移至函数后出现引用生命周期编译错误

在主循环中对HashMap执行大小写不敏感的查找逻辑可以正常运行，但将该逻辑封装为函数后，编译器报错：returns a value referencing data owned by the current function，错误指向返回的(x86_instruction, x86_64_instruction)。

主循环正常运行的代码 #

let raised_word = word.to_uppercase();
let x86_instruction =
    names_to_instructions.get(&(Arch::X86, &*word)).map_or_else(
        || {
            names_to_instructions
                .get(&(Arch::X86, &raised_word))
        },
        |instr| Some(instr),
    );
let x86_64_instruction =
    names_to_instructions.get(&(Arch::X86_64, &*word)).map_or_else(
        || {
            names_to_instructions
                .get(&(Arch::X86_64, &raised_word))
        },
        |instr| Some(instr),
   );

封装后报错的函数代码 #

pub fn search_for_instr<'a>(
    word: &'a str, 
    map: &'a NameToInstructionMap<'a>
) -> (Option<&'a&'a Instruction>, Option<&'a&'a Instruction>) {
    let raised_word = word.to_uppercase();

    let x86_instruction =
    map.get(&(Arch::X86, &*word)).map_or_else(
        || {
            map
                .get(&(Arch::X86, &raised_word))
        },
        |instr| Some(instr),
    );
    let x86_64_instruction =
    map.get(&(Arch::X86_64, &*word)).map_or_else(
        || {
            map
                .get(&(Arch::X86_64, &raised_word))
        },
        |instr| Some(instr),
   );

    (x86_instruction, x86_64_instruction)
}

报错原因分析 #

问题出在生命周期绑定上：

• raised_word是函数内部创建的String，属于函数本地所有权。
• 当调用map.get(&(Arch::X86, &raised_word))时，传入的键包含一个指向raised_word的引用。HashMap的get方法返回的引用，其生命周期会和传入的键的生命周期绑定——也就是和raised_word的生命周期（仅限函数内部）绑定。
• 函数执行结束后，raised_word会被销毁，此时返回的引用就指向了已释放的内存，违反了Rust的内存安全规则，因此编译器报错。

主循环中没有问题，是因为所有引用和raised_word都处于同一个作用域，当作用域结束时一起被销毁，不存在悬空引用的风险。

解决方案 #

方案1：修改HashMap的键类型为拥有所有权的类型 #

将HashMap的键从(Arch, &str)改为(Arch, String)，这样HashMap内部存储的是完整的字符串所有权，查找时返回的引用仅和HashMap本身的生命周期绑定，与临时变量无关：

// 假设NameToInstructionMap现在定义为：
type NameToInstructionMap = HashMap<(Arch, String), Instruction>;

pub fn search_for_instr<'a>(
    word: &str, 
    map: &'a NameToInstructionMap
) -> (Option<&'a Instruction>, Option<&'a Instruction>) {
    // 先尝试原字符串查找
    let x86_instruction = map.get(&(Arch::X86, word.to_string()))
        // 失败则尝试大写字符串查找
        .or_else(|| map.get(&(Arch::X86, word.to_uppercase())));
    
    let x86_64_instruction = map.get(&(Arch::X86_64, word.to_string()))
        .or_else(|| map.get(&(Arch::X86_64, word.to_uppercase())));

    (x86_instruction, x86_64_instruction)
}

方案2：使用Cow减少不必要的内存分配 #

如果不想修改HashMap的键类型，可以用Cow（Clone-on-Write）来避免不必要的字符串复制，同时调整生命周期逻辑：

use std::borrow::Cow;

pub fn search_for_instr<'a>(
    word: &'a str, 
    map: &'a NameToInstructionMap<'a>
) -> (Option<&'a Instruction>, Option<&'a Instruction>) {
    // 仅当原字符串不是全大写时，才创建大写的String
    let raised_word: Cow<'a, str> = if word.chars().all(|c| c.is_uppercase()) {
        Cow::Borrowed(word)
    } else {
        Cow::Owned(word.to_uppercase())
    };

    // 先尝试原字符串查找，失败则用大写版本
    let x86_instruction = map.get(&(Arch::X86, word))
        .or_else(|| map.get(&(Arch::X86, raised_word.as_ref())));
    
    let x86_64_instruction = map.get(&(Arch::X86_64, word))
        .or_else(|| map.get(&(Arch::X86_64, raised_word.as_ref())));

    (x86_instruction, x86_64_instruction)
}

注意：此方案仅在HashMap的键引用的生命周期长于函数时有效（比如键是'static或者来自函数外部的字符串），否则仍会出现生命周期问题。

方案3：提前预处理所有键为大写 #

如果业务允许，可以在初始化HashMap时，把所有指令名称都转换为大写存储，这样查找时直接将输入转为大写即可，无需两次查找，从根源上避免大小写匹配的问题：

// 初始化HashMap时统一转为大写
let mut names_to_instructions = HashMap::new();
names_to_instructions.insert((Arch::X86, "MOV".to_string()), Instruction::Mov);
// ...其他指令

// 查找函数简化为：
pub fn search_for_instr<'a>(
    word: &str, 
    map: &'a NameToInstructionMap
) -> (Option<&'a Instruction>, Option<&'a Instruction>) {
    let raised_word = word.to_uppercase();
    let x86_instruction = map.get(&(Arch::X86, raised_word.clone()));
    let x86_64_instruction = map.get(&(Arch::X86_64, raised_word));

    (x86_instruction, x86_64_instruction)
}

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