Rust构建HashMap时结构体字段作键触发E0382报错解决方案

业务场景为加载SQL表数据后构建HashMap，映射规则为：表对应结构体的指定字符串字段作为键，结构体实例本身作为值。
直接编写插入逻辑会触发E0382部分移动编译错误：

error[E0382]: use of partially moved value: `foo`
  --> src/main.rs:24:35
   |
24 |         foo_hashmap.insert(foo.a, foo);
   |                            -----  ^^^ value used here after partial move
   |                            |
   |                            value partially moved here
   |
   = note: partial move occurs because `foo.a` has type `String`, which does not implement the `Copy` trait

对String字段调用clone()虽然可以通过编译，但数据库读取的字符串长度不确定，全量clone字符串的内存开销较高，需要低开销的解决方案。
复现问题的最小代码：

use std::collections::HashMap;

struct Foo {
    a: String,
    b: String,
}

fn main() {
    let foo_1 = Foo {
        a: "bar".to_string(),
        b: "bar".to_string(),
    };

    let foo_2 = Foo {
        a: "bar".to_string(),
        b: "bar".to_string(),
    };

    let foo_vec = vec![foo_1, foo_2];

    let mut foo_hashmap = HashMap::new();

    foo_vec.into_iter().for_each(|foo| {
        foo_hashmap.insert(foo.a, foo);  // foo.a.clone() will make this compile
    });
}

之前尝试用Rc<RefCell<String>>包裹字段的方案不可行，原因是RefCell<T>没有实现Hash trait，无法作为HashMap的键，且该场景下完全不需要内部可变性，属于不必要的引入。

按照开销从低到高排序，可选择以下方案：

• 方案1：移除结构体中冗余的key字段，零拷贝实现
  绝大多数场景下，HashMap的键本身可以通过Map的API（遍历、get_key_value等）拿到，value中不需要冗余存储和key完全相同的字段。直接把key字段从value的结构体定义中拆分出来，插入时解构原结构体，将字段分别移动到键和值的位置，全程没有任何内存拷贝，是性能最优的方案。
  示例代码：

  use std::collections::HashMap;
  
  // 原结构体用于承接数据库查询结果
  struct Foo {
      a: String,
      b: String,
  }
  
  // HashMap的value结构体不再冗余存储a字段
  struct FooValue {
      b: String,
  }
  
  fn main() {
      let foo_1 = Foo {
          a: "bar".to_string(),
          b: "bar".to_string(),
      };
  
      let foo_2 = Foo {
          a: "bar".to_string(),
          b: "bar".to_string(),
      };
      let foo_vec = vec![foo_1, foo_2];
      let mut foo_hashmap = HashMap::new();
  
      foo_vec.into_iter().for_each(|foo| {
          // 解构拆分原结构体，所有字段直接移动，无clone开销
          let Foo { a, b } = foo;
          foo_hashmap.insert(a, FooValue { b });
      });
  }
  

• 方案2：使用引用计数智能指针共享字符串所有权，极低开销
  如果业务逻辑要求value必须保留完整的原结构体（比如兼容现有接口定义），就用Rc<str>（单线程场景）或Arc<str>（多线程场景）作为字符串字段的类型。不要加多余的RefCell，Rc/Arc本身已经实现了Hash、Eq等HashMap要求的trait，克隆时仅拷贝指针、给引用计数+1，开销和复制一个8字节整数相当，远低于克隆整个String的开销。
  示例代码：

  use std::collections::HashMap;
  use std::rc::Rc;
  
  struct Foo {
      a: Rc<str>, // 用Rc包裹字符串，共享所有权
      b: String,
  }
  
  fn main() {
      let foo_1 = Foo {
          a: Rc::from("bar"), // 数据库读取的字符串可以直接通过Into转换为Rc<str>
          b: "bar".to_string(),
      };
  
      let foo_2 = Foo {
          a: Rc::from("bar"),
          b: "bar".to_string(),
      };
  
      let foo_vec = vec![foo_1, foo_2];
      let mut foo_hashmap = HashMap::new();
  
      foo_vec.into_iter().for_each(|foo| {
          // 仅克隆Rc指针，不复制底层字符串数据
          let key = foo.a.clone();
          foo_hashmap.insert(key, foo);
      });
  }
  

• 不要用Cow<'static, str>解决这个场景：如果是数据库读取的动态字符串，会走Cow::Owned变体，克隆时依然会全量拷贝String内存，和直接clone String没有开销差异，解决不了问题。
• 不要用Rc<RefCell<String>>：既引入了不必要的运行时借用检查开销，也因为RefCell未实现Hash trait无法作为HashMap的键，完全不适用。

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