为何HashMap::get与HashMap::entry接受的键类型不同？

先对比两个方法的签名：

• HashMap::entry的签名：

  pub fn entry(&mut self, key: K) -> Entry<'_, K, V>
  

  这个设计逻辑很直接：因为entry方法可能需要插入新键（比如调用or_insert时），必须持有键的所有权，所以直接接收K类型参数。

• HashMap::get的签名：

  pub fn get<Q>(&self, k: &Q) -> Option<&V>
  where
      K: Borrow<Q>,
      Q: Hash + Eq + ?Sized,
  

  这种泛型约束的核心目的是提升查询灵活性，同时避免不必要的性能损耗，具体原因如下：

1. 避免不必要的克隆，支持轻量查询键 #

如果HashMap的键类型是String，若只能用&K（即&String）作为查询参数，那当我们手里只有&str类型的字符串片段时，就必须先把&str克隆成String再取引用查询——这完全是无意义的性能浪费。

而通过Borrow<Q>约束，String实现了Borrow<str>，所以我们可以直接传入&str查询HashMap<String, V>，无需任何克隆操作：

let map: HashMap<String, i32> = [("foo".to_string(), 42)].into();
// 直接用&str查询，无需克隆成String
assert_eq!(map.get("foo"), Some(&42));

2. 兼容智能指针包装的键类型 #

如果HashMap的键是智能指针类型（比如Arc<String>、Rc<u32>），这种设计允许我们直接用底层类型的引用查询，不需要先解包智能指针。

比如键是Arc<String>时，我们可以用&String或者&str查询，因为Arc<String>同时实现了Borrow<String>和Borrow<str>：

use std::collections::HashMap;
use std::sync::Arc;

let map: HashMap<Arc<String>, i32> = [(Arc::new("bar".to_string()), 100)].into();
// 用&str直接查询，无需处理Arc
assert_eq!(map.get("bar"), Some(&100));

3. 给自定义类型留足扩展空间 #

如果我们自己定义了一个类型，只要让它实现Borrow<Q>（其中Q是HashMap键类型可借用的目标类型），同时Q满足Hash + Eq，就能用这个自定义类型的引用来查询HashMap。这种设计让API的扩展性更强，能适配更多业务场景。

总结来说，get方法的泛型约束是为了在只读查询场景下，最大化查询灵活性，避免不必要的内存分配和克隆；而entry因为涉及可能的插入操作，必须持有键的所有权，所以只能接收K类型参数。

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