第二章 Electron核心原理高频面试题
本章定位 覆盖Electron三大核心原理：进程模型、通信机制、安全机制。面试官常从「原理理解深度」和「安全细节」两个维度考察，以下结构化内容帮你快速建立答题框架。
核心原理速查表
| 核心原理 | 重点掌握 | 高频考点 |
|---|---|---|
| 进程模型 | 主进程（BrowserWindow）、渲染进程（WebContents）、辅助进程（GPU等） | 进程崩溃恢复、WebContents生命周期、remote模块已废弃 |
| 通信机制 | ipcMain/ipcRenderer、contextBridge、preload脚本 | 同步vs异步、安全桥接、性能优化（invoke/handle） |
| 安全机制 | 沙箱、nodeIntegration:false、contextIsolation:true、CSP | XSS防御、remote替代方案、preload权限控制 |
面试问答一：请你解释Electron的进程模型
面试官考察点
- 是否清楚主进程与渲染进程的角色和职责
- 是否理解进程间单向架构（渲染进程不允许直接访问系统资源）
- 是否了解Electron的进程管理（如WebContents、BrowserWindow）
回答框架
- 概述：Electron使用Chromium多进程架构，主进程（Node.js）负责创建窗口与系统交互
- 主进程：只有一个，管理应用生命周期、菜单、原生对话框等
- 渲染进程：每个BrowserWindow对应一个渲染进程（沙箱化），运行Web页面
- 通信：渲染进程通过IPC与主进程通信，不能直接访问操作系统API
- 辅助进程：GPU、网络等由Chromium自动管理
示例回答
Electron基于Chromium多进程架构。主进程是Node.js环境，负责窗口创建、系统交互（如文件对话框）。每个BrowserWindow对应一个独立渲染进程，运行网页代码。渲染进程默认沙箱化，不能直接使用Node API，只能通过IPC与主进程通信。这种模型保证了安全性，但需注意进程崩溃后通过webContents.reload()恢复。
可能追问
- 渲染进程崩溃后如何恢复？
- 为什么Electron不能像传统网页一样使用window.open？
- Electron 27+中remote模块被移除，你的替代方案是什么？
避坑提醒 不要混淆“主进程”和“渲染进程”的职责，尤其不要认为渲染进程可以直接require('fs')。还要注意Electron升级后remote模块已移除，面试中应主动提到不再使用remote，改用ipcMain/ipcRenderer。
面试问答二：描述Electron的通信机制，并说明如何保证安全性
面试官考察点
- 是否熟悉ipcMain、ipcRenderer、contextBridge的用法与区别
- 是否理解preload脚本的作用与权限控制
- 是否了解同步通信（sendSync）的风险与替代方案
回答框架
- 通信方式：ipcMain/ipcRenderer通过send、on、handle进行异步通信，invoke/handle是推荐模式
- 安全桥接：使用contextBridge暴露有限的API到渲染进程，替代直接暴露ipcRenderer
- preload脚本：在渲染进程创建时运行，拥有有限的Node权限，可定义桥梁函数
- 禁止同步通信：sendSync会阻塞主进程，应避免使用；使用invoke/handle处理请求
- 最佳实践：contextIsolation:true，nodeIntegration:false，preload仅暴露必要方法
示例回答
推荐使用ipcMain.handle + ipcRenderer.invoke 异步模式。在preload中用contextBridge暴露安全函数，例如：contextBridge.exposeInMainWorld('api', { openFile: () => ipcRenderer.invoke('open-file') })。渲染进程只能调用这些受限API，无法直接访问ipcRenderer或其他Node模块。同步sendSync会卡死主进程，必须避免。
可能追问
- contextBridge暴露的对象如何避免被篡改？
- preload脚本中为什么不能直接使用require？
- 多个渲染进程如何共享数据？是否可以使用SharedWorker？
避坑提醒 不要遗漏contextBridge！很多候选者只讲ipcMain/Renderer，却未提安全桥接机制。另外注意：preload中的require仅在nodeIntegration开启时可用，且Electron 12+默认nodeIntegration:false，所以一般使用preload中的内置API（如ipcRenderer）但通过contextBridge暴露。
面试问答三：谈谈Electron的安全机制，如何防御XSS与远程注入？
面试官考察点
- 是否了解沙箱（sandbox）、contextIsolation、nodeIntegration等配置
- 是否熟悉Content Security Policy（CSP）在Electron中的使用
- 是否知道如何避免渲染进程绕过安全限制
回答框架
- 核心配置：contextIsolation:true（隔离渲染进程与preload），nodeIntegration:false（禁止直接使用Node）
- 沙箱：启用sandbox后渲染进程无法使用任何Node能力，preload中可调用的方法也受限制
- CSP：在HTML中设置Content-Security-Policy，限制脚本来源、禁止内联脚本
- 防止远程代码执行：不信任用户输入，严格校验IPC消息类型
- 弃用remote：使用ipcMain/ipcRenderer替代remote的通信方式
示例回答
Electron安全基线：设置contextIsolation:true、nodeIntegration:false、sandbox:true。在HTML中加入<meta http-equiv="Content-Security-Policy" content="default-src 'self'">，阻止内联脚本与外部资源。preload中仅通过contextBridge暴露白名单API。此外，主进程对所有IPC消息做参数校验，防止渲染进程伪造消息执行危险操作。
可能追问
- sandbox模式对性能有什么影响？
- 如何允许部分渲染进程加载外部资源？
- Electron的remote模块为什么被废弃？
避坑提醒 不要只提沙箱而不提CSP！很多高级面试官会考察CSP配置细节，以及如何处理eval()或setTimeout字符串执行。另外注意：sandbox模式下preload中只能使用有限的Electron API，不能使用Node模块（除process等少数），面试时需表达清楚。
面试加分技巧 在回答核心原理时，主动对比旧版（remote、nodeIntegration:true）与新版（contextBridge、安全沙箱）的演进，体现你对Electron版本迭代的跟进。能说出Electron 12、14、20三个关键版本的重大安全变动，会让面试官印象深刻。