DeepChat项目中的多Tab会话并发问题分析与解决方案

问题背景

在DeepChat这类基于Electron的桌面聊天应用中，多标签页(Tab)架构是一个常见的设计模式。这种架构允许用户同时进行多个独立的对话会话，每个Tab理论上应该保持完全的隔离性。然而，在实际开发过程中，我们发现当存在以下两种操作同时发生时，会出现会话数据混乱的问题：

1. 在Tab A正在进行内容生成时
2. 用户新建Tab B并开始生成新内容

这种情况下，两个Tab的会话数据可能会发生交叉污染，导致用户看到错误的对话内容。

问题根源分析

经过深入的技术排查，我们发现问题的核心在于以下几个方面：

1. 全局状态管理缺陷

项目中的chatStore虽然设计为单例模式，并通过tabId区分不同Tab的数据，但在实际实现中存在以下问题：

• 状态更新操作缺乏原子性保证
• 多个异步操作之间可能插入其他Tab的操作
• 全局变量的读写没有适当的同步机制

2. 消息处理流程的隐式行为

在threadPresenter.sendMessage方法中，存在一个容易被忽视的隐式行为：当role参数为'user'时，该方法不仅会创建用户消息，还会自动创建并返回一个assistant消息。这种隐式行为在多Tab并发场景下容易导致消息归属混乱。

3. 异步流程控制问题

项目中存在大量连续的await调用，这些调用之间没有对共享状态进行保护。例如：

const a = await operation1(); // 读取全局状态
await operation2();          // 可能被其他Tab操作打断
const b = await operation3(); // 再次读取全局状态，此时可能已改变

这种模式在多Tab环境下极易导致状态不一致。

解决方案

针对上述问题，我们实施了以下改进措施：

1. 强化状态隔离

• 为每个Tab建立完全独立的状态副本
• 在Tab切换时强制执行状态同步
• 引入状态快照机制，确保异步操作期间状态一致性

2. 重构消息处理流程

• 将隐式的消息创建行为改为显式调用
• 引入消息事务机制，确保消息创建的原子性
• 为每条消息添加严格的Tab标识和时序标记

3. 改进异步控制流

• 对关键路径的异步操作添加互斥锁
• 减少不必要的全局状态依赖
• 引入操作队列，确保同一Tab的操作顺序执行

技术实现细节

状态管理优化

我们重新设计了状态管理系统，引入了以下机制：

class TabStateManager {
  constructor() {
    this.tabStates = new Map();
    this.locks = new Map();
  }

  async withTabState(tabId, callback) {
    const lock = this.getLock(tabId);
    await lock.acquire();
    try {
      const state = this.getOrCreateState(tabId);
      return await callback(state);
    } finally {
      lock.release();
    }
  }
}

消息处理重构

新的消息处理流程明确区分了用户消息和助手消息的创建：

async function handleUserMessage(tabId, content) {
  return await tabStateManager.withTabState(tabId, async (state) => {
    const userMsg = await createMessage(tabId, 'user', content);
    const assistantMsg = await createMessage(tabId, 'assistant');
    return { userMsg, assistantMsg };
  });
}

经验总结

通过解决这个问题，我们获得了以下宝贵的经验：

1. 在Electron多窗口/多Tab应用中，全局状态管理必须格外谨慎
2. 隐式行为在多线程/多进程环境下是危险的来源
3. 异步操作中的状态一致性需要特别设计保障机制
4. 自动化测试对于并发问题的发现至关重要

这个问题也提醒我们，在桌面应用开发中，用户可能以任何顺序执行操作，开发者不能假设用户会按照特定顺序使用功能，必须为各种可能的操作序列做好准备。