Electron 主进程和渲染进程通信

引入现象

在刚接触 Electron 时，你也许会有这样的疑惑：主进程和渲染进程不是同一个应用里的代码吗，为什么不能直接共享变量？ 明明我在主进程里定义了一个全局变量，咋渲染进程那边就是 undefined 呢？又或者，我在渲染进程里调用了一个函数，主进程怎么听不见，完全没反应？乍一看，这俩像是活在不同世界，彼此无法直接对话。

其实，你的感觉没错！Electron 中主进程 和渲染进程 本来就跑在两个隔离的进程（Process）里。出于安全原因，这两种进程不能直接通信 ，也就无法直接共享内存或调用彼此的函数。就像处于不同沙盒里的两个脚本，互相看不到对方的变量。要让他们交换信息，必须通过专门的"信使"才行。这种信使就是我们接下来要聊的 IPC 机制。不过，在深入技术之前，我们先来八卦一下：Electron 为啥要搞出两个进程，两套上下文，这不是给自己添乱吗？

通俗解释机制

要弄清楚主进程和渲染进程的隔离，我们得从 Electron 的架构说起。其实 Electron 之所以这么设计，很大程度上是继承了 Chromium 浏览器的多进程架构 。还记得早期的浏览器吗？所有页面和逻辑都在一个进程 里跑，这样虽然开销小，但坏处是一旦某个网页崩溃、卡死，整个浏览器都跟着遭殃。Chrome 为了解决这个问题，干脆把每个标签页放进自己的进程 里运行，并由一个浏览器主进程统一调度管理。这样一个页面出问题，只影响它自己，不会拖垮全局。Electron 正是借鉴了这个思路：它也分成了主进程和渲染进程两类，类似于 Chrome 的浏览器进程和渲染进程。

如图所示，Electron 将 Node.js 环境嵌入到了 Chromium 的多进程架构中。主进程 （左上方的大盒子）负责管理应用生命周期和操作系统相关的功能（例如创建原生窗口、菜单等），并运行着 Node.js。渲染进程 （右侧的两个盒子）各自对应一个应用窗口，在其中渲染 Web 页面（前端代码），底层由 Blink/Webkit 内核驱动。主进程和每个渲染进程之间通过 IPC 通道连接（图中标注 "IPC" 的链路），彼此内存隔离，无法直接共享变量或调用函数。

这么做有什么好处呢？打个比方：主进程就像后台的控制中心，而渲染进程更像独立的浏览器页签 。每个渲染进程各管各的 ，只操心自己那一亩三分地（对应的页面）。如果某个渲染进程意外崩溃了，主进程和其他窗口理论上还能照常运行，应用不会整体挂掉。这提高了稳定性。另外，安全性 也大大提升 ------ 渲染进程主要运行网页相关的脚本，我们可不想让它随便直接调用操作系统功能。如果渲染进程里的恶意代码能直接访问主进程的资源，那后果不堪设想。所以 Electron 有意限制 渲染进程不能直接调用原生 GUI API，必须通过主进程代理。举个例子，在浏览器环境的页面中，你不允许直接操作本地文件系统，但通过主进程你可以。这样的职责划分保证了就算加载的不可信网页脚本，也不会直接威胁系统。

总结一下：主进程 =在 Node.js 环境中运行，掌管应用的大局（窗口创建、文件系统、原生交互等）；渲染进程 =在浏览器环境中运行，负责页面的UI展示和用户交互逻辑。两者各司其职，彼此隔离运行。那隔离开来后，他们如何协作完成任务呢？这就需要一个通信机制，把两边的话传递过去 ------ 这就是 IPC（进程间通信）。下面我们就来拆解 Electron 中主进程和渲染进程**"隔空喊话"**具体是怎么实现的。

深入技术原理

IPC 通信机制

IPC 是 Inter-Process Communication 的缩写，顾名思义就是进程间通信 。在 Electron 中，官方提供了 ipcMain 和 ipcRenderer 两个模块，专门用来在主进程和渲染进程之间传递消息。通信的规则很简单：约定一个频道（channel）名称，一方发送消息，另一方监听该频道收到消息 。这个频道名可以是任意的字符串，就像起个暗号，只要双方对上暗号就能交换信息。而且通信是双向的，同一个频道既可以渲染进程发主进程收，也可以反过来主进程发渲染进程收。

小科普 ：其实 Chromium 内部早有一套进程通信机制，Electron 不过是在上面封装了方便使用的接口而已。ipcMain 和 ipcRenderer 本质上都是 EventEmitter 实例，通过事件机制来收发消息。

Electron 的 IPC 提供了多种通信模式，常见的有以下几种：

渲染进程 -> 主进程（单向） ：渲染进程发送消息，主进程异步收到。例如用户点击按钮后，让主进程保存文件。这种情况渲染端不需要马上拿到结果，只管通知主进程去做事就好。实现上，渲染进程调用 ipcRenderer.send(channel, ...args) 发消息，主进程用 ipcMain.on(channel, (event, ...args) => { ... }) 监听该频道即可。需要注意，这种 send/on 方式是 单向的，没有返回值------也就是说渲染进程发完消息不会等待任何结果。如果渲染进程需要知道任务结果，需要主进程再通过另一个渠道通知它（下面会说如何主->渲染发送）。
渲染进程 -> 主进程（双向 RPC） ：渲染进程请求，主进程处理后需要给出结果返回。例如渲染进程请求主进程读取某个文件，然后把内容返回给它。这种模式下我们希望像调用函数那样拿到返回值。Electron 提供了 ipcRenderer.invoke(channel, ...args) 和 ipcMain.handle(channel, handler) 来实现请求-响应 模式。渲染进程调用 invoke 会返回一个 Promise，主进程用 handle 注册处理函数，函数里可以 return 返回值或一个 Promise，最终 invoke 的 Promise会resolve结果。换句话说，这相当于远程调用主进程函数，等待其结果。这种模式能够拿到返回值，代码写起来也更直观。实际上，在 Electron 5 以后这已经成为推荐的 IPC 方式之一，因为它避免了手动管理回调。有了它，很多时候甚至都不需要再使用下面要说的同步通信或 remote 模块了。
主进程 -> 渲染进程（单向） ：有时主进程也需要主动给渲染进程发消息，比如主进程完成了某个后台任务，要通知前端更新UI，或者主进程捕获到系统事件希望页面做出反应。主进程可以通过获取窗口的 webContents 来发送消息，方法是 browserWindow.webContents.send(channel, ...args)。只要渲染进程这边用 ipcRenderer.on(channel, (event, ...args) => { ... }) 注册了监听器，就能收到主进程推送的数据。当然，如果消息是针对某个特定窗口的，主进程得拿到对应窗口的 webContents 对象。Electron 提供了一些便利：在 ipcMain.on 的回调里，你可以通过 event.sender 拿到发送消息的那个渲染进程的 webContents。或者干脆用 event.reply(channel, ...args) 直接回复发送方渲染进程。event.reply 其实就是对 event.sender.send 的封装，省得你自己获取 sender 再发一次。
（不常用）同步通信 ：Electron 还提供了一个同步阻塞式的方法：ipcRenderer.sendSync(channel, ...args)，对应主进程用 ipcMain.on 来处理并通过返回值回应。这个方法会阻塞渲染进程，直到主进程处理完消息并返回结果。所以除非万不得已，不然不推荐使用同步 IPC。因为它会卡住页面的线程，让用户界面在此期间停止响应。另外，同步 IPC 还有可能造成死锁（尤其在页面加载阶段）。大部分场景用异步的 invoke/handle 已经能替代同步需求。

可以看到，IPC 总的来说就是发布-订阅模型 ：一方发布消息，另一方订阅处理。根据是否需要回复，又分成了单向和双向两类模式。而无论哪种，底层都是在不同进程之间传递序列化的数据 ------ 注意，IPC 传的参数会被序列化复制，而非共享引用 。比如你从渲染进程传一个对象给主进程，主进程拿到的是那个对象的拷贝，而不是指向同一块内存。这也是为什么我们说不能共享变量，变量值只能通过消息拷贝过去。此外，传输的内容必须是可序列化的（可以JSON.stringify的），函数、DOM元素、类实例这些就没法直接传。不过基础类型、对象、数组这些日常数据类型都支持。

讲了这么多通信方式，大家可能发现一个问题：渲染进程到底是怎么拿到 ipcRenderer 这个模块来发送消息的？ 毕竟在浏览器环境下，可没有 ipcRenderer 这种玩意儿，全局对象只有 window、document 那些。是的，这就牵涉到 Electron 的另一个独特机制：Preload 脚本与上下文隔离。这个机制直接关系到渲染进程能否访问 Node.js、能否使用 IPC 模块。下面我们详细解释。

contextIsolation 与 Preload（上下文隔离与预加载脚本）

Electron 为了安全，提供了一个**上下文隔离（contextIsolation）**的选项。它的作用通俗地说就是：让渲染页面的 JS 代码运行在一个隔离的沙盒环境中，无法直接访问 Electron 和 Node.js 提供的高权限对象 。而我们的 Preload 脚本（预加载脚本）则运行在另一个上下文里，拥有 Node.js 的能力，可以充当两边的桥梁。

从 Electron 12 开始，contextIsolation 默认就是开启的（值为 true），官方强烈建议所有应用都保持这个默认设置。为什么要这样做？因为很多 Electron 应用会加载来自网络的内容或第三方网页，如果不给它们隔离开，等于这些页面脚本直接拿到了 Node.js 的全部能力，那简直是在计算机上开了扇大门，安全风险极高。这和我们前面提到的浏览器沙箱理念是一脉相承的：尽量保证网页内容和应用内核隔离。

开启上下文隔离后，会发生什么变化呢？渲染进程中的网页脚本将拿不到原先预加载脚本在 window 上注入的任何对象 。举例来说，如果没有隔离，你可以在 preload.js 里写 window.hello = 'world'，那么网页上的脚本就能直接访问到 window.hello 并得到 "world"。但如果隔离开 (contextIsolation: true)，当网页脚本去访问 window.hello 时却会得到 undefined！因为此时预加载脚本和网页脚本各有各的全局 window 对象，彼此不共享属性。简单说，预加载脚本和网页不在一个作用域。

那这样岂不是渲染页面什么都干不了了？别慌，Electron 给我们提供了**contextBridge 模块**，让预加载脚本可以安全地将特定功能暴露给渲染页面 。contextBridge.exposeInMainWorld(apiKey, apiObject) 方法可以把你指定的 apiObject 挂到隔离的网页环境的 window[apiKey] 上。通过这个机制，渲染页面虽然还是接触不到 Node.js 的所有东西，但能通过你提供的接口调用特定功能。

举个例子，假如我们想让渲染进程调用 IPC 发消息给主进程，我们可以在 preload.js 里这样做：

javascript 复制代码

// preload.js (运行于隔离上下文，可使用Node和ipcRenderer)
const { contextBridge, ipcRenderer } = require('electron')
contextBridge.exposeInMainWorld('electronAPI', {
    setTitle: (title) => ipcRenderer.send('set-title', title)
})

这样，渲染页面就可以通过 window.electronAPI.setTitle('新标题') 来调用预加载脚本里的函数，间接触发 ipcRenderer.send 发消息给主进程了。主进程只要有对应的 ipcMain.on('set-title', ...) 监听，就能收到。这正是官方文档里的一个示例：在渲染页面点击按钮，把输入的文本通过 IPC 发给主进程，主进程拿到后调用 BrowserWindow API 改变窗口标题。

需要强调的是，通过 contextBridge 暴露给渲染页面的 API 一定要做好过滤和限定 。千万别一股脑把整个 ipcRenderer 或 fs 模块之类直接暴露出去！官方文档明确指出，直接暴露高权限对象是不安全的做法。比如下面这样是错误的：

arduino 复制代码

// ❌ 不安全的做法：暴露整个 ipcRenderer.send
contextBridge.exposeInMainWorld('badAPI', {
    send: ipcRenderer.send  // 这样网页脚本可以发送任意IPC消息，存在安全风险
})

这样做等于把IPC的任意发送能力拱手送给了页面上的脚本 ，如果那里面有恶意代码，它可以利用你的IPC通道干各种坏事。而正确的方式是只暴露具体功能的函数，在内部调用IPC，并且只允许固定的通信频道。例如：

arduino 复制代码

// ✅ 安全的做法：暴露一个函数，内部调用特定的IPC通道
contextBridge.exposeInMainWorld('goodAPI', {
    loadPreferences: () => ipcRenderer.invoke('load-prefs')
})

如上，页面脚本只能调用 window.goodAPI.loadPreferences()，它背后实际发送的是固定的 load-prefs 请求，而不是随意指定频道。主进程对应写个 ipcMain.handle('load-prefs', ...) 来处理即可。这样我们就完成了一次受控的双向通信：页面 -> 预加载脚本（通过window.goodAPI调用）-> 主进程（处理并返回）-> 页面（Promise拿到结果）。

概括来说：contextIsolation 打开时，渲染页面无法直接使用 Node.js API，包括 ipcRenderer 。要通信必须通过预加载脚本，用 contextBridge 提供"白名单"接口给页面调用。虽然写起来稍微繁琐一点，但极大地提高了安全性。在 Electron 12+ 版本，这已经是标准范式。事实上，如果你创建 BrowserWindow 时没有特别关闭 contextIsolation，默认页面里是拿不到 window.require、ipcRenderer 这些东西的；而如果你之前用了 remote 模块，那在隔离模式下也会失效，需要改用 IPC。

remote 模块的小插曲 ：以前 Electron 有个方便但危险的东西叫 remote 模块，它可以让渲染进程直接调用主进程的函数或访问主进程的变量。例如 const { BrowserWindow } = require('electron').remote 就能在渲染进程直接拿 BrowserWindow 类来创建新窗口，或者 remote.getGlobal('myVar') 直接获取主进程的全局变量。听起来很爽对吧？然而这其实暗地里也是用 IPC 实现的，每次调用 remote 都在进程间通讯，性能开销不小，而且会留下安全隐患（等于又打开了一个共享通道）。因此，在新版本中 remote 默认被禁用了 ，官方也不推荐使用它。如果你用到，需要安装额外的包 @electron/remote 并手动启用。这么折腾就是为了逼大家用更安全的 IPC + preload 方案来取代 remote 的功能。

了解了这些原理，接下来通过一个具体的小实例，看看主进程和渲染进程如何通过 IPC 传递数据 ，以及在启用 contextIsolation 的情况下怎样实现安全通信。

实例分析：IPC 通信实战

场景：假设我们要在应用的渲染页面上做一个"打开文件"按钮，用户点击按钮时，由渲染进程请求主进程打开系统的文件对话框（dialog.showOpenDialog），让用户选文件，主进程拿到文件路径后再传回渲染进程，在页面上显示选择的文件路径。

这个场景很常见，也足以涵盖我们上面讨论的通信机制：渲染->主进程请求（需要拿结果），主进程->渲染回复数据。而且因为调用了 dialog 模块（Electron 的原生对话框）属于主进程才能干的事，所以必须通过 IPC 让主进程代劳。

我们将分三步来实现：

主进程：注册 IPC 处理器 -- 在主进程的 main.js 中，通过 ipcMain.handle 注册一个频道（比如 'dialog:openFile'）的处理函数，当渲染进程请求打开文件对话框时，主进程执行该函数并返回结果。
预加载脚本：暴露调用接口 -- 在 preload.js 中，使用 contextBridge.exposeInMainWorld 提供一个全局函数给渲染页面，例如 window.electronAPI.openFile()。这个函数内部调用 ipcRenderer.invoke('dialog:openFile')，向主进程发出请求。
渲染页面：发起请求并接收结果 -- 在页面的渲染进程代码中（例如一个 <script>或renderer.js文件），调用上面暴露的 window.electronAPI.openFile()，并拿到返回的 Promise。在 Promise 完成后获取用户选中的文件路径，在页面上显示出来。

按照上述思路，各部分代码示例如下：

（1）主进程 main.js ：创建 BrowserWindow 时记得设置 preload.js，并启用 contextIsolation（默认通常已启用）。然后注册 IPC 通道的处理器：

csharp 复制代码

// main.js （主进程）
const { app, BrowserWindow, ipcMain, dialog } = require('electron')
const path = require('path')

function createWindow () {
  const win = new BrowserWindow({
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      contextIsolation: true  // 确保开启隔离
      // nodeIntegration 可以为 false，确保页面脚本不能直接用 Node
    }
  })
  win.loadFile('index.html')
}

// 主进程准备好时创建窗口
app.whenReady().then(createWindow)

// 注册 IPC 处理器，响应渲染进程的文件打开请求
ipcMain.handle('dialog:openFile', async () => {
  const result = await dialog.showOpenDialog({ properties: ['openFile'] })
  if (result.canceled) {
    return null  // 用户取消了
  } else {
    return result.filePaths[0]  // 返回选中的文件路径（字符串）
  }
})

这里主进程通过 ipcMain.handle('dialog:openFile', handler) 注册了一个异步处理函数。当收到渲染进程 'dialog:openFile' 请求时，就会执行 dialog.showOpenDialog 打开系统文件选择窗。showOpenDialog 是异步的，返回一个 Promise，我们用 await 拿到结果后，把用户选的第一个文件路径返回（如果取消则返回 null）。有了 ipcMain.handle，Electron 会自动把返回值发送回发出请求的渲染进程。

（2）预加载脚本 preload.js：桥接渲染和主进程，暴露安全接口：

javascript 复制代码

// preload.js （预加载脚本，在主进程创建BrowserWindow时被注入）
const { contextBridge, ipcRenderer } = require('electron')

// 将 openFile 函数暴露给渲染进程
contextBridge.exposeInMainWorld('electronAPI', {
  openFile: () => ipcRenderer.invoke('dialog:openFile')
})

这样，我们在渲染页面中就有一个全局的 window.electronAPI.openFile() 可以调用。一旦调用，它内部会使用 ipcRenderer.invoke 发出 'dialog:openFile' 请求，并拿到主进程返回的 Promise。这个模式与官方文档提供的 contextBridge 用法相同，只是换了具体频道名称。

（3）渲染页面：调用接口并处理结果。例如，在你的 HTML 文件里，有一个按钮：

xml 复制代码

<!-- index.html -->
<button id="openBtn">选择文件</button>
<div id="filePathDisplay"></div>
<script>
  // 渲染进程脚本
  const btn = document.getElementById('openBtn');
  const display = document.getElementById('filePathDisplay');
  btn.addEventListener('click', async () => {
    // 调用预加载暴露的接口，等待Promise返回结果
    const filePath = await window.electronAPI.openFile();
    console.log('用户选择的文件路径：', filePath);
    if (filePath) {
      display.textContent = `选中的文件: ${filePath}`;
    } else {
      display.textContent = '未选择文件';
    }
  });
</script>

当用户点击按钮时，渲染代码调用了 window.electronAPI.openFile()。由于我们在 preload 中定义了这个方法，它实际上触发的是 ipcRenderer.invoke('dialog:openFile')，于是发消息给主进程。主进程前面通过 ipcMain.handle 注册了监听器，所以收到请求后打开文件对话框，等待用户操作。用户选好文件后，主进程的 handler 返回文件路径，这个返回值经由 IPC 自动传回渲染进程，作为 window.electronAPI.openFile() 返回的 Promise 的结果。于是渲染这边 await 到文件路径，就可以拿来用了（这里简单地显示在页面上或控制台打印）。

通过这个实例，你可以清晰地看到：渲染进程和主进程虽身处不同"世界"，但可以通过 IPC 这座桥梁交换数据。整个过程其实就像演双簧------渲染进程这边喊一嗓子："诶，主进程老哥，帮我问下用户要打开哪个文件！"，主进程弹出对话框后回喊："用户选了这个文件！"------两边靠"喊话"（消息传递）来同步信息，而不是直接拿对方的数据。这样的设计确保了双方在各自的地盘上运行，各司其职，同时又能合作完成任务。

值得一提的是，上述代码中我们始终保持了 contextIsolation 为 true ，并且没有开启不安全的 nodeIntegration。渲染页面只能通过 window.electronAPI 这一扇"门"跟外界（主进程）交流，别的高危接口一概接触不到。这种最小暴露原则 极大地降低了风险：就算页面上跑了恶意脚本，它能调用的也只有我们允许的 electronAPI.openFile，顶多弹出一个系统对话框，搞不出别的幺蛾子。在实际开发中，也请务必遵循这个原则，该隔离的一定要隔离，该过滤的一定别大意。

系统认知：通信方式的对比与建议

经过上面的讲解，我们已经了解了 Electron 主进程和渲染进程通信的主要方式。最后来做一个全面梳理 ，帮大家系统性地认识各种通信途径的优缺点，以及在什么场景下适合采用哪种：

ipcRenderer.send + ipcMain.on （异步单向）：渲染进程触发主进程执行某动作，不需要直接回应结果。
✅ 优点：简单快捷， fire-and-forget 模式，无须处理返回值。适用于例如通知主进程记录日志、发送通知等无需确认结果的场景。渲染进程不会被堵塞，可以继续执行其他任务。
❌ 缺点：无法直接获取主进程处理结果。如果需要结果反馈，必须主进程再通过 webContents.send 发送回去，额外增加代码量和频道管理。也可能因缺少回应机制，难以确定主进程是否完成了任务。
ipcRenderer.invoke + ipcMain.handle （异步双向/RPC）：渲染进程请求主进程并等待结果。
✅ 优点：代码风格类似调用异步函数，主进程可以直接 return 结果，渲染进程拿到 Promise。实现双向通信更方便 。非常适合请求数据、执行需要结果确认的操作，例如获取配置、读取文件、计算结果等。相比 send/on，不需要手动设计额外的回应消息，逻辑清晰。
❌ 缺点：比单向略有开销，主进程处理完之前渲染进程需等待（虽然不阻塞UI线程，但功能上要等Promise）。不适合特别频繁的即时通信（频繁RPC可能性能受到影响，不过一般问题不大）。另外，要确保主进程 handler 一定会 return，否则渲染端的 Promise 会一直悬而不决。
ipcMain（webContents）.send + ipcRenderer.on （主进程主动推送）：主进程主动发送消息到渲染进程。
✅ 优点：允许主进程在任意时刻通知渲染进程，比如主进程完成了后台任务、收到了系统事件或用户托盘菜单点击等，可以及时把消息推给前端更新UI。这种模式在需要全局状态变更通知 、多窗口同步 时很有用（主进程作为中央协调者广播消息）。
❌ 缺点：主->渲染必须指定目标窗口（webContents）发送，代码上稍微麻烦一点。如果一个事件需要通知多个窗口，主进程需要遍历发送或采用 BrowserWindow.getAllWindows() 找到所有窗口发消息。渲染进程这边还要提前注册好对应频道的监听。并且这也是单向的，如果渲染端需要回应，仍得用别的IPC再传回去。
ipcRenderer.sendSync + ipcMain.on （同步请求）：渲染进程同步等待主进程返回结果。
✅ 优点：在极少数需要同步结果的场景下提供了一种方案，代码写起来像常规函数调用一样，不用Promise。在主进程立即能返回结果且非常快速的情况下，或许会考虑用它。
❌ 缺点：严重阻塞渲染进程。一旦主进程处理稍慢一点，界面就会卡死。而且如果主进程再通过任何方式等待渲染进程（比如对话框等），会造成死锁。因此除非你十分确定需要它，否则不要使用。同样功能使用 invoke 异步完全可以替代，而且用户无感知延迟。
@electron/remote 模块 ：让渲染进程直接调用主进程模块/函数的老办法。
✅ 优点：编码方便，不用自己写 IPC 消息，像在渲染进程直接用主进程的 API 一样。例如 remote.require('electron').BrowserWindow 或 remote.getGlobal('varName') 直接拿主进程的数据。以前不少 Electron 新手喜欢用它图省事。
❌ 缺点：性能差 、不安全 、而且已被废弃。remote 背后实际隐含了同步 IPC 调用，每调一次跨进程函数都有开销，频繁用会明显拖慢应用。更重要的是，它打破了原有的隔离，让渲染进程拿到了主进程的权力，这在加载远程内容时非常危险。因此 Electron 从 v12+ 开始默认禁用了 remote，需要开发者主动引入才能用。而大多数情况下，完全可以使用 IPC + preload 模式来实现同样功能，更加安全可控。

最后，再给出几点实践建议：

优先使用异步 IPC （send/on 或 invoke/handle），根据是否需要返回值选择具体方式。推荐优先考虑 ipcRenderer.invoke/ ipcMain.handle，因为它封装了应答流程，代码简洁且不易遗漏处理结果。ipcRenderer.send/ ipcMain.on 可用于简单的通知或触发，但若随后需要反馈，不妨直接用 invoke 实现，以免多维护一个回复通道。
避免同步调用。几乎所有场景都能用异步来解决，同步只会带来性能和死锁隐患。就算你觉得某个结果非拿不可，也尽量通过 Promise/回调把后续逻辑串起来，而不要堵塞线程等结果。
坚守安全默认值 。确保在 BrowserWindow 的 webPreferences 中开启了 contextIsolation: true（默认如此）且关闭了 nodeIntegration: false（如果加载的内容不可信）。不要因为一时省事在页面直接开 Node 集成，这相当于取消了渲染和主进程的隔离，风险极高。相反，应充分利用 preload 脚本去做桥梁。
最小化暴露接口 。通过 contextBridge.exposeInMainWorld 暴露给页面的 API，应仅限于页面真正需要的功能，而且尽可能简化。例如需要读取文件，就暴露一个 openFile() 方法，而不是整个 fs 模块。需要调用主进程某功能，就暴露一个封装了特定 IPC 的函数，而不是直接把 ipcRenderer丢过去。这样可以将潜在攻击面降到最低。
合理组织通信渠道 。随着应用复杂度提升，IPC 渠道可能会很多。建议对频道名称做一定的命名规范（比如加前缀区分模块），并在主进程集中管理 IPC 注册，避免频道冲突或难以维护。同时，主进程处理 IPC 时最好做基本的参数验证，勿盲信渲染发来的数据。可以参考官方安全指南中的建议，对 IPC 通信的发送方进行验证。

总而言之，Electron 中主进程与渲染进程的通信机制设计初衷就是在安全隔离 和功能实用 之间寻求平衡。我们不能也不该让它们直接共享状态，但是通过 IPC，我们依然可以让应用的各个部分协调运作。正如官方所言，由于主、渲染进程职责不同，IPC 是执行许多常见任务的唯一方式（比如从 UI 调用原生API，或从主菜单触发页面改变）。掌握并遵循这些通信机制和最佳实践，我们就能既保证应用安全，又实现主进程和渲染进程之间顺畅高效的"对话"！祝你玩转 Electron，写出稳健又牛逼的桌面应用。