Electron 进程模型与 IPC 通信

面试问题：请解释 Electron 的进程模型，以及主进程和渲染进程的区别。

面试官考察点：

• 是否理解多进程架构背后的安全性设计
• 能否说清每个进程的生命周期与职责
• 是否知道渲染进程的沙箱隔离机制

回答框架：

1. 一句话定义：主进程是应用入口，负责窗口管理、原生 API；渲染进程负责页面渲染，每个窗口独立。
2. 对比：主进程有 Node.js 全部能力；渲染进程默认无 Node 环境（v12+ 后 contextIsolation 默认开启）。
3. 补充：渲染进程可通过 preload 脚本安全暴露有限接口。

简短示例回答：

Electron 采用 Chromium 多进程架构。主进程运行 Node.js，管理窗口、菜单、原生对话框；每个渲染进程对应一个 BrowserWindow，负责页面渲染，默认不访问 Node API。两者通过 IPC 通信。v12 后默认启用 contextIsolation 和 sandbox，显著提升安全性。

可能追问：

• 沙箱模式下 preload 脚本可以做什么，不可以做什么？
• 如何让渲染进程具备文件系统访问能力？

避坑提醒：不要混淆主进程与渲染进程的进程 ID 管理；注意 electron 12 之前版本可能未启用 contextIsolation，旧代码需说明兼容性。

面试问题：Electron 中如何进行进程间通信（IPC）？请举例说明。

面试官考察点：

• 是否掌握 ipcMain / ipcRenderer 双向通信
• 能否说出 contextBridge 的推荐用法
• 是否了解过时的 remote 模块及替代方案

回答框架：

1. 主流方式：preload 脚本通过 contextBridge.exposeInMainWorld 暴露 API，内部使用 ipcRenderer。
2. 主进程监听 ipcMain.on / handle，渲染进程使用 ipcRenderer.invoke（推荐）或 send。
3. 举例：渲染进程点击按钮 → 调用 preload 暴露的 selectFile() → 主进程打开对话框 → 返回路径。

简短示例回答：

推荐使用 contextBridge 安全通信。在 preload 中定义：contextBridge.exposeInMainWorld('electronAPI', { selectFile: () => ipcRenderer.invoke('select-file') })。主进程用 ipcMain.handle('select-file', async () => { /* 打开对话框 */ })。渲染进程直接 window.electronAPI.selectFile() 即可。

可能追问：

• ipcRenderer.send 和 ipcRenderer.invoke 有什么区别？什么场景用 send？
• 主进程向渲染进程主动发送消息如何实现（使用 webContents.send）？

避坑提醒：不要直接暴露 ipcRenderer 到渲染进程；不要在主进程监听器中执行耗时同步操作，会导致渲染进程卡死。

面试问题：在 Electron 中，如何安全地实现主进程与渲染进程的通信？请谈谈最佳实践。

面试官考察点：

• 安全意识：XSS 防护、私有 API 暴露控制
• 是否掌握 contextIsolation、sandbox、preload 三者关系
• 能否结合 CSP 和内容脚本做纵深防御

回答框架：

1. 必须开启 contextIsolation（v12+ 默认）和 sandbox。
2. preload 脚本仅暴露最少必要方法，使用 channel 白名单。
3. 主进程对接收的输入进行校验（如路径合法性、参数类型）。
4. 可选：设置 CSP 头限制渲染进程加载资源。

简短示例回答：

最佳实践：1) 在 BrowserWindow 中设置 contextIsolation: true, sandbox: true；2) preload 中通过 contextBridge 暴露 API，每个 IPC channel 做参数校验；3) 主进程 handler 内部验证数据（如检测路径是否在白名单内）；4) 启用 Content-Security-Policy 防止 XSS 注入。

可能追问：

• 如果用户需要访问文件系统，sandbox 模式下如何处理？
• Electron 的 contextBridge 内部如何防止原型链污染？

避坑提醒：不要为了便利关闭 contextIsolation 或允许 nodeIntegration 为 true；不要使用 contextBridge.exposeInMainWorld 传递复杂对象或函数引用，会导致内存泄漏或安全漏洞。

项目名称：跨平台桌面文档编辑器（团队协作版）

业务背景：为内部研发团队提供一款轻量级 Markdown 编辑器，支持实时预览、文件目录树、粘贴图片自动上传、Git 版本管理。

规模指标：

• 月活跃用户：3.2 万；开屏启动响应小于 1.5 秒
• 同时打开文档数：最高 12 个渲染进程
• IPC 消息量：平均每分钟 800 次（文件自动保存、同步状态）

技术栈：Electron 22 + React 18 + TypeScript + contextBridge + ipcMain.handle + electron-store + log4js-node

核心难点：

• 多渲染进程对同一文件并发写入导致数据竞争 → 主进程加读写锁 + 队列化
• 大文件（>100MB）打开时 UI 阻塞 → 使用 FileReader 分片 + 渲染进程 requestIdleCallback
• 安全审计要求进程间传递路径不能包含 `../` → 主进程使用 path.resolve 并校验

面试高频追问：

• 你用 ipcMain.handle 还是 ipcMain.on？为什么选择 handle（返回 Promise，天然支持异步响应）？
• 并发写入锁如何实现？简单描述读写锁 + 渲染进程等待队列。
• 如何调试渲染进程中的 IPC 性能？使用 performance.now 埋点或 Electron 的 IPC 分析工具。

可迁移回答话术：