Rust 中如何保持全局 HashMap 与结构体内部 HashMap 值同步？

核心问题根因 #

你遇到的问题本质是两个设计缺陷叠加：

1. 数据冗余：Roster.names存储了全局MY_ITEMS中Person实体的副本，重复存储天然就需要双向同步，很容易产生不一致
2. 重入锁冲突：持有MY_ITEMS的全局锁时，在作用域内再次尝试加锁就会触发WouldBlock错误，导致无法同步更新第三方实体

最优方案：消除数据冗余，Roster只存ID引用 #

完全去掉Roster.names中的实体存储，改为只存储Person的ID列表，全局MY_ITEMS作为唯一真值源，所有实体详情查询都通过ID去全局HashMap获取。

// 修改Roster定义，不存实体副本
#[derive(Clone, Debug, PartialEq, Eq)]
pub struct Roster{
  pub id: String,
  pub person_ids: Vec<String>, // 仅存Person ID，不存实体
}

该方案从根源消灭了同步需求，没有冗余就不会出现数据不一致的问题，是扩展性最好、维护成本最低的方案。

兼容现有设计方案：拆分锁作用域，批量更新 #

如果你一定要保留Roster存储实体的现有设计，可以把锁的持有逻辑拆分为计算、写入两个阶段：

1. 计算阶段：持有全局锁取出需要操作的实体，完成业务逻辑计算，把所有需要更新的K-V对暂存到临时HashMap，完成后立刻释放全局锁
2. 写入阶段：重新申请全局锁，把暂存的所有修改批量写入全局HashMap，不会产生重入锁冲突
   示例代码片段：

// 暂存所有待更新的实体
let mut pending_updates = HashMap::new();

// 计算阶段：只做逻辑处理，处理完立刻释放锁
{
    let mut global_lock = MY_ITEMS.lock().unwrap();
    let Some((r1_wrapper, r2_wrapper)) = global_lock.get_pair_mut("roster 1", "roster 2") else {
        return;
    };
    let (Entity::Roster(r1), Entity::Roster(r2)) = (r1_wrapper, r2_wrapper) else {
        return;
    };

    // 执行人员转移逻辑
    let person_entry = r2.names.remove_entry(&String::from("Person 4")).unwrap();
    if let Entity::Person(mut p) = person_entry.1.clone() {
        p.roster_id = Some(r1.id.clone());
        r1.names.insert(person_entry.0.clone(), Entity::Person(p.clone()));
        // 把要更新的Person加入待更新列表
        pending_updates.insert(person_entry.0, Entity::Person(p));
    }
    // 把修改后的两个Roster也加入待更新列表
    pending_updates.insert(r1.id.clone(), Entity::Roster(r1.clone()));
    pending_updates.insert(r2.id.clone(), Entity::Roster(r2.clone()));
} // 全局锁在此处释放

// 写入阶段：批量更新所有修改
let mut global_lock = MY_ITEMS.lock().unwrap();
for (key, entity) in pending_updates {
    global_lock.insert(key, entity);
}

可选方案：实体层加内部可变性 #

将全局HashMap的Value改为Arc<Mutex<Entity>>，这样你从全局HashMap取出实体的Arc指针后就可以释放全局锁，后续修改实体只需要锁实体本身的Mutex，不需要再操作全局HashMap的锁，避免重入冲突：

use std::sync::Arc;

lazy_static! {
    static ref MY_ITEMS: Mutex<HashMap<String, Arc<Mutex<Entity>>>> = Mutex::new(HashMap::new());
}

该方案不需要修改上层业务逻辑，但会增加实体的访问成本，适合实体间依赖复杂、修改频繁的场景。

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