2. Electron架构核心知识速查：主进程与渲染进程、进程通信、沙箱模式
本章是Electron架构面试的基石。面试官通过主进程与渲染进程的职责划分、IPC通信机制、沙箱模式安全设计三大维度，考察你对Electron底层架构的理解深度。掌握这些核心概念，能帮你应对90%的架构类问题。
核心知识对比：主进程 vs 渲染进程
| 对比维度 | 主进程 (Main Process) | 渲染进程 (Renderer Process) |
|---|---|---|
| 核心职责 | 应用入口、窗口管理、系统原生API | UI渲染、用户交互、页面逻辑 |
| Node.js 访问 | 完全访问，可调系统模块 | 沙箱模式下受限，需桥接 |
| 实例数量 | 单例，整个应用唯一 | 每窗口一个，可多实例 |
| 调试方式 | --inspect 或 DevTools for Electron | 标准 Chrome DevTools |
| 生命周期 | 应用启动 → 退出 | 窗口创建 → 关闭 |
🎯 面试问题 1：请解释Electron中主进程和渲染进程的区别及各自职责。
面试官考察点：
- 是否理解Electron的双进程架构设计
- 能否清晰划分主进程与渲染进程的职责边界
- 是否了解沙箱模式对渲染进程的限制
回答框架：
- 先给出明确定义，区分两个进程的角色
- 对比职责边界，突出主进程的系统级能力和渲染进程的UI职责
- 简述通信方式（IPC）和安全限制（沙箱模式）
- 结合项目说明实际应用场景
示例回答： 主进程是应用入口，负责窗口生命周期管理、系统原生API调用和全局状态维护。渲染进程负责页面渲染和用户交互，通过IPC与主进程通信。沙箱模式下渲染进程无法直接访问Node.js API，需通过preload脚本桥接。
可能追问：
- 沙箱模式下渲染进程如何调用系统对话框？
- 主进程发生阻塞会有什么影响？如何优化？
- Electron 28中进程架构有哪些新变化？
⚠️ 避坑提醒： 不要混淆主进程和渲染进程的职责。常见错误：在渲染进程中直接使用
require('fs') 读写文件，或在主进程中执行大量DOM操作。牢记：主进程管系统，渲染进程管界面。
🎯 面试问题 2：Electron中进程间通信（IPC）有哪些方式？如何选型？
面试官考察点：
- 是否熟悉ipcMain / ipcRenderer 的API使用
- 能否区分 send/on 与 invoke/handle 的适用场景
- 是否了解 contextBridge 的安全桥接作用
回答框架：
- 说明IPC的两种模式：双向通信（send/on）和请求响应（invoke/handle）
- 强调 contextBridge + preload 是推荐的安全实践
- 对比各方式的适用场景与性能差异
- 指出已废弃的 remote 模块及其替代方案
示例回答： 进程间通信通过ipcMain和ipcRenderer实现，支持send/on双向通信和invoke/handle请求响应模式。推荐使用contextBridge在preload脚本中暴露接口，实现安全通信。避免使用已废弃的remote模块，优先选择invoke/handle模式，代码更清晰且性能更优。
可能追问：
- contextBridge 是如何隔离作用域的？
- 大量高频IPC调用如何优化？
- 主进程与渲染进程如何共享大对象？
⚠️ 避坑提醒： 切勿在渲染进程中直接
require('electron') 调用主进程API。remote模块已在Electron 14中废弃，新项目必须使用 contextBridge + preload 方案。面试时主动提及这点会加分。
🎯 面试问题 3：什么是Electron的沙箱模式？开启后有哪些限制和应对方案？
面试官考察点：
- 是否理解沙箱模式的安全设计目标
- 是否清楚沙箱模式对渲染进程的具体限制
- 能否给出沙箱模式下的功能适配方案
回答框架：
- 解释沙箱模式的本质：隔离渲染进程与Node.js API
- 说明开启方式：
webPreferences.sandbox: true - 列举限制：无法 require、无法访问系统资源、fs模块不可用
- 给出标准解决方案：preload + contextBridge + IPC代理
示例回答： 沙箱模式将渲染进程与Node.js API隔离，通过options.sandbox: true开启。开启后渲染进程无法直接require模块，需在preload中使用contextBridge暴露受限接口，由主进程代理执行系统操作，有效提升应用安全性，适合高安全需求场景。
可能追问：
- 沙箱模式下如何实现文件下载和保存？
- 沙箱模式对性能有什么影响？
- 如何在不开启沙箱的情况下保证安全？
⚠️ 避坑提醒： 不要为图方便全局关闭沙箱模式。正确的做法是：保持沙箱开启，通过preload按需暴露接口。如果面试中提到“为了使用Node.js API而关闭沙箱”，会被扣分。安全设计是Electron架构的核心竞争力。
📁 项目案例：企业级桌面IDE — CodeForge
| 项目名称 | CodeForge 企业级桌面IDE |
| 业务背景 | 为内部200+开发团队提供统一的前端开发环境，支持代码编辑、调试、版本管理，替代分散的本地工具链 |
| 规模指标 | 12个核心模块 · 80+视图组件 · 日活3000+ · 管理500+代码仓库 · 包大小压缩后约85MB |
| 技术栈 | Electron 28 + React 18 + TypeScript 5 + Node.js 20 + Webpack 5 + SQLite + CodeMirror 6 |
| 核心难点 |
|
| 面试高频追问 |
|
| 可迁移回答话术 |
|
💡 面试加分点： 主动提及“沙箱模式下使用
contextBridge.exposeInMainWorld 分模块暴露接口”和“使用 ipcMain.handle 替代 ipcMain.on 实现请求响应模式”，体现你对Electron安全最佳实践的掌握。
📌 复习提示： 本章三个核心知识点——进程职责划分、IPC通信选型、沙箱安全适配——是Electron架构面试的“铁三角”。建议结合CodeForge项目案例，用真实的架构决策和优化数据来支撑你的回答，让面试官看到你不仅有理论，更有实战深度。