📚 课程目录第4章 Electron进程模型与IPC通信面试题

4. Electron 进程模型与 IPC 通信

Electron 应用基于 Chromium 的多进程架构，理解主进程、渲染进程的职责边界以及 IPC 通信机制，是面试高频基础。本章聚焦进程模型核心概念、remote 模块的演进与替代方案、上下文隔离的安全实践，帮助你在面试中清晰展现架构认知。

🔍 面试问题 1：请简述 Electron 的主进程和渲染进程分别负责什么？进程间如何通信？

考察点	理解多进程架构、职责分配、IPC 基本用法
回答框架	① 明确主进程（Node.js 环境，控制窗口/菜单/系统交互）与渲染进程（Chromium 沙盒，渲染页面）的职责。② IPC 通信：主进程使用 ipcMain，渲染进程使用 ipcRenderer，通过 channel 收发消息。③ 安全建议：避免在渲染进程执行敏感操作，使用 preload 暴露有限 API。
示例回答	主进程管理应用生命周期、原生菜单、系统托盘，渲染进程负责页面渲染和用户交互。通信通过 ipcMain/ipcRenderer 异步消息实现，例如渲染进程请求文件读取，主进程处理后回复。我通常用 contextBridge 在 preload 中暴露安全 API，避免直接暴露 Node.js 能力。
可能追问	- 主进程与渲染进程之间能否同步通信？（ipcRenderer.sendSync 但会阻塞） - 多个渲染进程之间如何通信？（通过主进程转发或使用 MessagePort）
避坑提醒	不要混淆进程类型；渲染进程无法直接调用 Node.js API（除非 nodeIntegration: true），但生产环境应关闭 nodeIntegration，使用 preload 注入。

🔍 面试问题 2：Electron 的 remote 模块有什么作用？为什么 Electron 12 之后推荐废弃它？

考察点	对 remote 模块的理解、远程进程调用的安全风险、演进方向
回答框架	① 定义：remote 模块允许渲染进程直接访问主进程的对象（如 BrowserWindow）。② 问题：性能开销（序列化）、安全隐患（远程代码执行）、破坏进程隔离。③ 替代：使用 ipcMain/ipcRenderer 配合 contextBridge 显式暴露接口。
示例回答	remote 让渲染进程像本地调用一样操作主进程对象，但每次调用都会序列化传递，开销大且易引发安全漏洞。Electron 12 后标记为弃用，我迁移时将所有 remote 调用改为自定义 IPC 通道，通过 contextBridge 暴露主进程功能，既轻量又安全。
可能追问	- remote 模块的具体安全漏洞有哪些？（远程代码执行、原型链污染） - 迁移到 IPC 后如何保证类型安全？（使用 ipcMain.handle 返回 Promise，结合 ts 定义 message schema）
避坑提醒	不要回答“我还在用 remote”，会被认为安全意识落后；即使老项目有 remote，也要说明正在迁移方案。

🔍 面试问题 3：什么是上下文隔离（contextIsolation）？preload 脚本的作用是什么？

考察点	安全配置、preload 执行时机与范围、contextBridge 使用
回答框架	① contextIsolation 为 true 时，preload 脚本与网页运行在隔离的 JavaScript 上下文，避免直接访问 window 对象。② preload 脚本在渲染进程创建时执行，可访问 Node.js API（若 enableRemoteModule 关闭），通过 contextBridge.exposeInMainWorld 向网页暴露有限接口。
示例回答	contextIsolation 将 preload 和渲染进程的 JS 隔离，防止恶意网页通过原型链侵入 Node.js。我在 preload 中用 contextBridge.exposeInMainWorld('api', { showOpenDialog }) 暴露安全接口，网页只能调用预先定义好的方法，极大提升安全性。
可能追问	- contextIsolation 开启后 preload 中无法直接使用 window？ - 如何调试 preload 脚本？（用 console.log 查看 node 控制台）
避坑提醒	不要将 contextIsolation 设为 false 来简化开发；preload 不能引入复杂逻辑，仅做桥接。

项目名称	白板协同编辑器（Electron + WebRTC）
业务背景	为远程教育团队提供实时白板协作，支持画笔、图形、文本、图片上传，低延迟同步。
规模指标	日活用户 8k+，单房间最大并发 50 人；白板操作延迟 < 200ms；支持 Mac/Windows/Linux。
技术栈	Electron 16 + React + TypeScript + contextIsolation + ipcMain.handle / ipcRenderer.invoke + WebRTC + Canvas
核心难点	① 白板操作数据量大，需要 IPC 高效传递（使用 Transferable 对象）。② 依赖 old remote 模块的迁移，全部替换为 IPC handler。③ 多窗口间数据同步（通过主进程维护全局状态）。
面试高频追问	- 为什么使用 ipcRenderer.invoke 而不是 send？ - 如何处理 IPC 消息丢失？（重试 + 超时） - 渲染进程内存溢出如何排查？ - preload 中如何封装安全类型？
可迁移回答话术	“我们在项目中完全弃用了 remote 模块，所有跨进程调用通过预定义的 schema 在 preload 中暴露。比如打开本地文件对话框，渲染进程调用 window.api.showOpenDialog()，实际走 contextBridge 暴露的 invoke('dialog:open')，主进程使用 ipcMain.handle 异步响应。这样既保证了类型安全，也符合安全最佳实践。”

💡 面试官偏好： 现场手写一段 contextBridge + ipcMain.handle 的代码片段，展示你对安全架构的掌握。准备好 preload.ts 和 main.ts 的短例。

⚠️ 常见失分点： 回答中主动使用“remote”模块推荐方式；忽视 contextIsolation 默认值变化（Electron 12 后默认 true）；渲染进程直接调用 Node.js API 且未提 preload。