📚 课程目录第4章进程通信与IPC机制

4. 进程通信与 IPC 机制

Electron 的多进程架构决定了进程间通信（IPC）是应用的核心能力。面试中会重点考察你对 ipcMain/ipcRenderer 的使用、contextBridge 的安全性设计，以及如何替代逐步废弃的 remote 模块。下面从高频问答到真实项目案例逐一拆解。

核心要点：面试官期望你能清晰区分同步/异步通信、掌握 contextBridge 的安全暴露方式，以及结合 ipcRenderer.send / invoke 替代 remote 的具体实践。

面试问题	请用代码示例说明如何使用 ipcMain 和 ipcRenderer 实现渲染进程到主进程的通信。
考察点	基本 API 使用、通道命名规范、同步与异步的区别。
回答框架	1) 主进程监听通道 → 2) 渲染进程发送/调用 → 3) 返回结果；分别给出 `send`+`on` 和 `invoke`+`handle` 两种模式。
示例回答	“主进程使用 `ipcMain.handle('get-data', async (event, arg) => { ... })`；渲染进程使用 `const result = await ipcRenderer.invoke('get-data', arg)`。推荐 `invoke`/`handle` 避免阻塞渲染进程。”
可能追问	• 如果必须使用同步通信，你会怎么设计？ • 如何传递 Buffer 或大文件？ • 多个渲染进程如何共享一个主进程处理结果？
避坑提醒	不要在主进程监听器中直接调用 `event.sender` 发送大量数据，会造成内存泄漏；优先使用 `BrowserWindow.webContents.send` 主动推送。

面试问题	为什么推荐使用 contextBridge 暴露 API？请给出具体实现。
考察点	安全性意识、预加载脚本的作用、`contextIsolation` 配置。
回答框架	1) 启用 `contextIsolation: true` → 2) 在预加载脚本中使用 `contextBridge.exposeInMainWorld` → 3) 将 IPC 方法暴露为全局对象。
示例回答	“在预加载脚本中定义：`contextBridge.exposeInMainWorld('electronAPI', { openFile: () => ipcRenderer.invoke('dialog:openFile') })`。渲染进程通过 `window.electronAPI.openFile()` 调用，无需直接访问 Node.js 或 Electron 内部 API。”
可能追问	• 为什么不使用 `nodeIntegration: true`？ • 如何限制暴露的 API 只能被指定源调用？ • 渲染进程被 XSS 攻击后，contextBridge 能起到什么保护作用？
避坑提醒	不要将整个 `ipcRenderer` 对象直接暴露出去，否则渲染进程可以调用任何通道；只暴露方法而不是属性，减少风险。

面试问题	Electron 已弃用 remote 模块，你会用什么方案替代？
考察点	对官方废弃原因的理解、替代方案（IPC 消息传递 + 预加载脚本）、性能与维护的权衡。
回答框架	1) 分析 remote 的缺点（同步调用、安全风险） → 2) 使用 `ipcMain.handle` + `ipcRenderer.invoke` 异步替代 → 3) 对于 Dialog 等原生模块，通过预加载脚本暴露特定方法。
示例回答	“替代 `remote.dialog.showOpenDialog` 时，主进程注册 `ipcMain.handle('dialog:open')`，预加载脚本暴露 `openDialog()`。渲染进程调用 `window.electronAPI.openDialog()` 即可。”
可能追问	• 如果迁移现有大量使用 remote 的代码，你有什么策略？ • 如何实现 `remote.getCurrentWindow()` 的功能？ • 有没有使用 `@electron/remote` 包的场景？
避坑提醒	不要在新项目中启用 `enableRemoteModule` 兼容旧代码，这会导致安全漏洞且无法通过 Electron 后续版本审核。

实战提示：很多面试官会追问“如果渲染进程被注入恶意代码，如何防止攻击？” 回答要点：contextIsolation: true + sandbox: true + contextBridge 只暴露必要方法，且参数做类型校验。

项目名称	Electron 多标签文件管理器
业务背景	给企业用户提供本地文件管理工具，支持多标签页、拖拽上传、实时搜索。
规模指标	日活 5k、单进程可打开 20+ 标签页、文件列表每秒刷新 60fps。
技术栈	Electron 25 + Vue 3 + Vite + IPC 消息队列 + RxJS（流式处理）
核心难点	• 大量文件读取不能阻塞主进程 → 使用 Worker 线程 + IPC 流式返回 • 每个标签页独立渲染进程，关闭时需清理 IPC 监听器避免泄漏 • 原生菜单（右键、拖拽）需通过 contextBridge 暴露，但保持跨平台统一
面试高频追问	• 如何监控 IPC 调用频率，防止渲染进程过度请求？ • 如果主进程意外重启，如何恢复渲染进程的 IPC 状态？ • 你如何设计 IPC 超时机制？
可迁移回答话术	“我们采用 IPC 请求队列 + 超时回调的方式，每个请求带有唯一 ID，主进程处理完成后主动推送结果。关闭标签页时调用 `removeAllListeners` 清理通道，避免一次泄漏导致内存爆炸。”

避坑提醒：项目案例中不要只提“用了IPC”，要量化指标（如并发请求量、响应时长），并说明如何做异常兜底（重启、重试、降级）。面试官看重你对生产环境稳定性的思考。