跳到主要内容

多窗口状态同步方案？（主题/登录态/业务数据一致性）

考察点​

  • 多窗口架构下的状态一致性设计
  • 单一数据源思想在桌面端的落地

参考答案​

1. 问题本质​

多窗口各自是独立渲染进程、独立 JS 上下文——每个窗口里的 store 都是独立副本。用户在 A 窗口改了主题，B 窗口不会自动更新。需要一个同步机制保证"一处改、处处新"。

2. 方案对比​

方案原理适用缺点
主进程单一数据源状态存主进程，变更广播全局状态（主题/登录态/配置）每次读写要 IPC
localStorage + storage 事件同 partition 共享存储，变更触发事件低频小数据只传字符串，无结构
BroadcastChannel同源页面广播简单通知无法持久化，主进程不参与
状态库 + IPC 中间件各窗口 store 通过中间件与主进程双向同步复杂业务状态实现复杂

3. 推荐方案：主进程单一数据源 + 订阅广播​

架构：

        ┌─────────────┐
        │   主进程     │
        │  StateStore │ ← 唯一数据源（登录态/主题/配置）
        └──────┬──────┘
     set/get   │   broadcast('state:changed')
    ┌──────────┼──────────┐
    ▼          ▼          ▼
 窗口A       窗口B       窗口C
（各窗口本地 store 只是主进程状态的镜像缓存）

实现：

// ===== 主进程：状态中心 =====
class StateCenter {
  constructor() {
    this.state = { theme: 'dark', user: null };
  }

  set(key, value, sourceWebContents) {
    this.state[key] = value;
    // 广播给所有窗口（包括发起者，保证时序一致）
    for (const win of BrowserWindow.getAllWindows()) {
      win.webContents.send('state:changed', { key, value });
    }
  }

  get(key) {
    return this.state[key];
  }
}

ipcMain.handle('state:set', (e, { key, value }) => stateCenter.set(key, value, e.sender));
ipcMain.handle('state:get', (e, key) => stateCenter.get(key));
ipcMain.handle('state:get-all', () => stateCenter.state);
// ===== preload =====
contextBridge.exposeInMainWorld('state', {
  set: (key, value) => ipcRenderer.invoke('state:set', { key, value }),
  getAll: () => ipcRenderer.invoke('state:get-all'),
  onChange: (cb) => {
    const listener = (_e, payload) => cb(payload);
    ipcRenderer.on('state:changed', listener);
    return () => ipcRenderer.removeListener('state:changed', listener);
  },
});
// ===== 渲染进程：与前端状态库集成（zustand 示例）=====
import { create } from 'zustand';

const useGlobalState = create((set) => ({
  theme: 'dark',
  user: null,
  // 初始化：从主进程拉全量
  init: async () => set(await window.state.getAll()),
  // 写操作：先写主进程，等广播回来更新本地（单一数据流）
  setTheme: (theme) => window.state.set('theme', theme),
}));

// 订阅主进程广播 → 更新本地 store
window.state.onChange(({ key, value }) => {
  useGlobalState.setState({ [key]: value });
});

关键设计点：

  • 写走主进程、读等广播：不在本地先改再同步（避免多窗口并发写冲突），时序由主进程串行化
  • 本地 store 只是只读镜像，读取无 IPC 开销
  • 新窗口创建时 state:get-all 全量初始化，之后靠增量广播

4. 简化方案：localStorage 事件（低频场景可用）​

// 窗口 A 写入
localStorage.setItem('theme', 'dark');

// 同 partition 的窗口 B 自动收到 storage 事件
window.addEventListener('storage', (e) => {
  if (e.key === 'theme') applyTheme(e.newValue);
});

优点：零主进程代码。缺点：只支持字符串、无主进程参与（主进程不知道状态变了）、高频写入性能差。只适合"窗口间同步 UI 偏好"这类轻场景。

5. 注意点​

  1. 广播给已销毁窗口要先判 isDestroyed()
  2. 窗口未 ready 时消息丢失 → 新窗口用 get-all 拉取初始化，不靠历史消息
  3. 高频状态（如进度条）不适合走主进程广播（每个变更都是 N 次 IPC），高频状态点对点推送
  4. 状态持久化（electron-store）与内存同步是两件事：持久化在主进程 set 时顺带做

面试话术​

核心思想是"主进程做单一数据源"：写操作一律 invoke 到主进程，主进程更新后广播，各窗口本地 store 只是只读镜像——这样多窗口并发写由主进程串行化，天然无冲突。新窗口 get-all 初始化解决消息时序问题。低频轻量场景可以用 localStorage storage 事件偷懒，但高频/关键状态必须走主进程方案。

常见追问​

  • 多窗口同时写同一状态怎么保证一致？ 主进程单线程串行处理 set，后到的覆盖先到的，广播顺序即最终顺序——单一数据源的串行化优势。
  • 主进程重启（崩溃恢复）状态丢吗？ 内存态会丢，所以关键状态在 set 时同步持久化，重启后从磁盘恢复再广播。