Borrow 和 AsRef 都可以实现引用到引用的转换，但 Borrow 对相等性和哈希语义施加了严格的合同保障。当一个类型实现 Borrow<T> 时，它承诺 borrow() 返回一个与原始类型通过 Eq 相等并产生相同哈希值（通过 Hash）的值。AsRef 缺乏这些约束；它仅允许廉价转换，而不要求转换后的视图保持相同的哈希或相等性行为。HashMap 在其 get 方法中需要 Borrow，因为它必须确保作为 String 插入的键可以可靠地使用 &str 检索，确保这两种类型映射到同一内部桶并在冲突解决过程中相等比较。
您正在为一个 HTTP 代理设计一个高性能的路由表，其中路由键以拥有的 String 对象存储，但传入请求提供作为从网络缓冲区解析的 &str 切片的路径段。
您评估了三种实现策略。首先，您可以在查找时将所有键标准化为 String，以确保类型一致性；但这由于每个请求时的分配代价过高而被证明不可行。其次，您考虑使用 AsRef<str> 作为查找边界，允许 String 和 &str 转换为 &str；然而，AsRef 允许实现，其中引用的数据可能使用不同的 Unicode 规范化形式或编码，导致 “café” 作为 String 和 “café” 作为 &str 哈希到不同的桶，并且尽管逻辑相等仍导致缓存未命中。第三，您采用 Borrow<str>，它合同保障 String::borrow() 和 &str 产生相同的 Hash 和 Eq 结果，从而确保一致的桶索引。
您选择 Borrow 方法，因为它消除了每个请求的分配，同时保留了正确路由解析所需的哈希一致性。结果是一个零复制的查找机制，可以接受网络中的 &str 并正确匹配预插入的 String 路由，而没有语义漂移。
为什么在 HashMap 查找中使用 AsRef<str> 而不是 Borrow<str> 会导致微妙的检索失败？
虽然 AsRef<str> 允许将 String 和 &str 都转换为 &str，但它无法保证转换后的引用的哈希与原始拥有值的哈希匹配。HashMap 使用哈希值来确定存储桶；如果 String 和 &str 对于相同的逻辑内容产生不同的哈希（例如，由于内部表示或规范化不同），查找将搜索错误的桶并返回 None，尽管键是存在的。Borrow 通过要求 hash(x.borrow()) == hash(x) 和 x.borrow() == x 来防止这一点，确保异构类型在逻辑上相等时总是映射到相同的存储位置。
为什么 HashMap 需要同时满足 Borrow 和 Eq/Hash 特性边界，考虑到 Borrow 已经暗示了相等性语义？
Borrow 在拥有和借用表示之间确立了等价关系，但 Eq 和 Hash 定义了实际的比较和哈希算法。Borrow 只保证这些算法在类型边界内产生一致的结果；它并没有实现它们。HashMap 需要 Eq 以解决桶内的冲突，并需要 Hash 来最初计算桶索引。没有 Borrow，映射就无法安全地接受 &str 来查找 String 键；没有 Eq 和 Hash，它根本无法执行必要的比较或计算哈希值。
当通过智能指针投影时，Borrow 与 Deref 有何不同，为什么 HashMap 依赖于 Borrow 作为 String 键而不是 Deref 强制转换？
Deref 提供对目标类型的自动强制转换，并暗示了引用关系，但它并不强制要求智能指针与其目标之间保持哈希或相等性的一致性。一个假设的智能指针可以 Deref 到不同于用于哈希的内部表示的缓存或变换视图。Borrow 明确要求借用的视图保持与原始值相同的 Hash 和 Eq 语义。HashMap 之所以对 String 使用 Borrow，是因为它必须确保 “key”（作为 String）和 “key”（作为 &str）在同一桶中发生碰撞；仅靠 Deref 强制转换缺乏 String::deref() 和 &str 共享相同哈希实现合同的正式保证，而 Borrow 则对此不变式进行了规范化。