Rust入门：枚举作为键初始化静态HashMap遇Hash trait绑定问题

我是Rust新手，目前正在学习。我定义了第一个SkFormatter trait，其to_sk方法接收Key枚举和is_foreign布尔值参数，用于给字符串添加前缀（及根据is_foreign添加后缀）。为了实现前缀的常量映射，我创建了单元式枚举Key，随后尝试用其作为键初始化静态HashMap：

trait SkFormatter {
  fn to_sk(&self, key:Key, is_foreign: bool) -> String;
}

pub enum Key {
  Metal,
  Wood,
}

use std::collections::HashMap;
static KEY_TO_PRE:HashMap<Key,&str> = HashMap::from([
  (Key::Metal,"MT-"),
  (Key::Wood, "WD-"),
]);

编译时报错：the trait bound Key: std::hash::Hash is not satisfied。我疑惑单元式枚举默认应为整数类类型，为何不具备哈希性？另外我也考虑过用match语法实现，但不确定重复调用时的性能表现如何。

单元式枚举无默认Hash实现的原因 #

Rust的枚举（包括单元式）不会自动派生Hash、Eq、PartialEq这类trait——哪怕它底层是整数表示。这是Rust显式优先的设计原则：不会默认给类型添加可能不需要的trait实现，避免潜在的意外行为。

要解决编译错误，只需给Key枚举加上派生注解，让编译器自动生成这些trait的实现：

#[derive(Hash, Eq, PartialEq)]
pub enum Key {
  Metal,
  Wood,
}

HashMap的键必须同时实现Hash和Eq，加上这三个派生后就能满足要求了。

match与HashMap的性能对比 #

对于你这种只有2个枚举变体的场景，match的性能远优于HashMap：

• match会被编译器优化为直接的分支跳转（类似C语言的switch），时间复杂度严格O(1)，完全没有运行时哈希计算、表查找的开销。
• 哪怕是静态初始化的HashMap，每次查找仍需计算哈希值、定位哈希表桶，虽然少量元素下开销不大，但肯定比不过match的直接跳转。

如果Key的变体数量很少（比如个位数），直接用match是最优选择，代码也更直观：

fn get_prefix(key: Key) -> &'static str {
    match key {
        Key::Metal => "MT-",
        Key::Wood => "WD-",
    }
}

只有当Key变体数量极多（几十上百个），或者需要动态修改映射关系时，HashMap才更合适。

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