10.5 窗口通信与数据共享方案

在实际的 Electron 应用中，随着功能模块的增多，你通常不会只开一个窗口。比如一个应用可能有主编辑窗、设置窗、预览窗，甚至多个独立的文档窗口。这时就需要面对一个现实问题：窗口之间怎么通信？某个窗口的状态变化如何同步给另一个窗口？用户在一个窗口的操作如何触发其他窗口的更新？

这一节将梳理 Electron 里最常用的几种窗口间通信与数据共享方案，既不追求花哨，也不过度设计，只讲真正项目里能用上的办法。

10.5.1 通过主进程中转消息（标准 IPC 模式）

这是 Electron 官方最推荐、也最安全的窗口间通信模式。它的思路很简单：所有渲染进程都不直接互相通信，而是通过主进程这个“中央调度器”来转发消息。

具体做法：

发送窗口通过 ipcRenderer.send 或 ipcRenderer.invoke 将消息发给主进程，消息体中指定目标窗口的 ID。
主进程收到消息后，根据 ID 找到对应的 BrowserWindow 实例，使用 win.webContents.send 将消息派发给目标窗口。

例如，当一个设置窗口修改了主题颜色后，要通知所有已打开的主窗口实时更新：

渲染进程 A（设置窗口）

// 用户选择了深色主题，通知主进程转发
await ipcRenderer.invoke('broadcast-theme-change', 'dark');

主进程

ipcMain.handle('broadcast-theme-change', (event, theme) => {
  // 遍历所有窗口，排除发送窗口本身
  BrowserWindow.getAllWindows().forEach(win => {
    if (win.webContents.id !== event.sender.id) {
      win.webContents.send('theme-changed', theme);
    }
  });
});

渲染进程 B（主窗口）

ipcRenderer.on('theme-changed', (event, theme) => {
  // 立即切换主题
});

这种模式有几个优点：

符合 Electron 的安全模型，各窗口仍然在隔离的渲染进程中运行，不直接暴露对方的上下文。
消息流转路径清晰，所有跨窗口行为都能在主进程的日志中集中追踪。
可轻松扩展为广播、点对点、按角色分发等高级策略，逻辑完全由主进程控制。

10.5.2 共享主进程状态（内存级数据共享）

当你的多个窗口需要共享同一份数据（比如当前登录用户信息、全局配置、实时协作数据）时，没必要每个窗口都去独立维护一份状态，也不需要通过 IPC 来回同步。更好的做法是在主进程中保存一份共享数据，然后各个渲染进程按需读取或订阅变更。

这可以看作是一种“前端 Redux/Vuex 主进程版”。具体实现方式：

在主进程中维护一个 JavaScript 对象（或使用 Map），作为全局状态。
渲染进程通过 ipcRenderer.invoke 获取当前快照，或通过主进程主动推送（webContents.send）来接收变更通知。
对于变更频繁的数据，也可以给每个渲染进程分配一个“变更计数器”，让渲染进程可以根据计数判断是否需要拉取最新数据，避免主进程频繁推送带来的性能开销。

示例：全局用户信息共享

// 主进程
let currentUser = null;

ipcMain.handle('get-current-user', () => currentUser);

ipcMain.on('update-current-user', (event, user) => {
  currentUser = user;
  // 通知所有窗口用户信息已变更
  BrowserWindow.getAllWindows().forEach(win => {
    win.webContents.send('user-updated', currentUser);
  });
});

这种方法特别适合配置项、登录状态、许可证信息等全局只读或低频变更的数据。它减少了窗口间的直接通信，让数据所有权更明确，也降低了渲染进程维护状态的复杂度。

10.5.3 使用本地存储的同步机制（localStorage + ipc）

Electron 的每个渲染进程拥有独立的 localStorage，这与浏览器标签页的行为一致：不同窗口之间的 localStorage 默认是隔离的。但 Chromium 提供了一种特殊的行为：当两个窗口加载的是同一个页面（相同协议、域名、端口），且使用了 nodeIntegrationInSubFrames 或 webContents.session 共享会话时，它们的 localStorage 是共享的。

不过依赖共享 localStorage 来做实时通信不是一个可靠的方案，因为 localStorage 的变更不会自动触发其他窗口的 storage 事件（在 Electron 中，storage 事件仅在同一渲染进程中跨 frame 触发，不同窗口间不会收到通知）。所以通常的做法是：

一个窗口修改 localStorage 后，通过 IPC 通知主进程“某数据已更新”。
主进程广播给其他窗口，告知它们去重新读取 localStorage。

这种“本地存储 + IPC 通知”的组合，既利用了 localStorage 的持久化能力，又解决了跨窗口同步的问题。但它多了一层手动通知，适合不太频繁变动的数据（如用户偏好、插件配置），对于高频率的实时数据，建议还是走主进程内存共享或 IPC 直接传递。

10.5.4 使用 BroadcastChannel API（同源窗口）

如果你的多个窗口加载的是同一个 html 页面（同源的渲染上下文），且都运行在 contextIsolation 开启的安全模式下，Electron 是支持标准 BroadcastChannel API 的。也就是说，你可以用纯 Web API 实现窗口间通信，而不需要经过主进程。

示例：

// 渲染进程 A
const channel = new BroadcastChannel('app-data');
channel.postMessage({ type: 'theme', value: 'dark' });

// 渲染进程 B（同源）
const channel = new BroadcastChannel('app-data');
channel.onmessage = (event) => {
  console.log('收到消息:', event.data);
};

优点是简单免配置，缺点是窗口必须同源（通常意味着同一个 HTML 文件或来自相同 file:// 路径），且不适用于需要主进程权限的操作。如果你的应用大部分窗口都复用相同的渲染页面，用 BroadcastChannel 来传递界面状态也是一个轻量级的好选择。

10.5.5 共享 Worker 和 SharedWorker（实验性方案）

Electron 的 Chromium 支持 SharedWorker，这意味着你可以在同源的多个渲染进程之间共享一个 Worker 线程， Worker 内可以维护一份共享内存数据，各个窗口通过消息端口与该 Worker 通信。这种方式能够实现真正的共享状态，且不需要主进程介入。

不过在实际项目中，SharedWorker 的使用率并不高，主要是因为：

它的 API 相对复杂，调试体验不佳。
Electron 对 Node.js 在 Worker 中的使用有限制（nodeIntegrationInWorker 配置），可能导致一些本地能力无法直接使用。
对于大多数桌面应用来说，主进程中介方案已经完全够用，且更容易理解和维护。

除非你的应用有特别高的实时数据共享需求（比如多窗口协作编辑同一份文档），否则不太需要深入这块。

10.5.6 选择方案的实用建议

在实际开发中，不必拘泥于一种方案，可以根据数据的性质灵活组合：

| 数据类型 | 推荐方案 |
|--------|--------|
| 全局配置、用户偏好（低频变更） | 主进程内存共享 + 变更通知（方案 2） |
| 实时协作数据、聊天消息（高频） | IPC 主进程广播（方案 1） |
| 同源窗口间的 UI 状态同步 | BroadcastChannel（方案 4） |
| 需要持久化存储的场景 | “localStorage + IPC 通知”组合（方案 3） |

核心原则：让数据的归属权清晰，尽量减少窗口间的直接耦合。不管采用哪种方法，最好把所有跨窗口通信的通道整理在一个统一的模块中（比如创建一个 windowBridge.ts），这样当后期需要替换通信方式时，改动范围能被很好地控制。

牢记一点：Electron 中的窗口通信从来不是技术难题，而是一个架构设计问题。在项目初期就定下清晰的通信策略，可以避免后期面对几十个窗口时陷入消息混乱的泥潭。