第三章 主进程与渲染进程职责划分与最佳实践
职责划分是 Electron 架构的基石，也是面试中最高频的考察点之一。错误的划分会导致性能劣化、安全漏洞与架构混乱。本章从职责边界、通信模式、常见错误三个维度，帮你构建清晰的进程职责认知体系。
contextBridge 安全暴露。
| 维度 | 主进程（Main Process） | 渲染进程（Renderer Process） |
|---|---|---|
| 核心职责 | 系统 API、窗口管理、原生能力 | UI 渲染、用户交互、业务逻辑 |
| 访问能力 | Node.js 全 API、系统资源 | DOM / CSS、受限 Node.js（需预加载） |
| 生命周期 | 应用启动 → 退出 | 窗口创建 → 关闭 |
| 安全隔离 | 无特殊限制 | 必须启用 contextIsolation |
| 典型场景 | 文件系统、原生菜单、系统通知 | 页面渲染、事件处理、动画 |
面试问题 ①
Electron 中主进程和渲染进程的职责如何划分？请说明核心原则。
- 职责边界界定
- 主进程能力清单（系统 API / 窗口 / 原生）
- 渲染进程能力清单（DOM / 交互 / 业务）
- IPC 桥接 + contextBridge 原则
主进程负责系统级操作：窗口管理、菜单注册、文件 I/O、原生对话框；渲染进程负责 UI 渲染与用户交互：DOM 操作、事件处理、界面动画。核心原则：主进程不操作 DOM，渲染进程不直接调用系统 API，所有跨进程通信经 IPC + contextBridge 安全桥接。
- 渲染进程需要访问文件系统怎么办？
- 主进程可以操作 DOM 吗？为什么？
- contextIsolation: false 有什么风险？
require('fs')，必须通过 IPC 委托。
面试问题 ②
主进程与渲染进程之间如何通信？请介绍几种常用模式与安全实践。
- IPC 基础：ipcMain / ipcRenderer
- 安全暴露：preload + contextBridge
- 通信模式：invoke/handle（双向）vs send/on（单向）
- 高频场景优化：SharedArrayBuffer / MessagePort
通过 preload 脚本 + contextBridge 暴露类型安全 API，主进程使用 ipcMain.handle 注册处理函数，渲染进程通过 ipcRenderer.invoke 调用。关键点：必须启用 contextIsolation，禁止直接暴露 ipcRenderer。
// preload.js
contextBridge.exposeInMainWorld('api', {
readFile: (path) => ipcRenderer.invoke('file:read', path)
});- 为什么不直接暴露 ipcRenderer？
- 如何进行进程间的广播通信？
- 大文件传输如何优化？
面试问题 ③
列举几个常见的进程职责划分错误，以及如何修复。
- 典型错误列举（3 个左右）
- 后果分析（性能 / 安全 / 稳定性）
- 修复方案与代码变更示例
- 预防措施：代码 review + 架构规范
常见错误：1）渲染进程直接 require('fs') → 改为 IPC 委托主进程；2）主进程执行大量计算阻塞 UI → 迁移到 Worker 线程；3）渲染进程间直接通信 → 通过主进程转发或 MessagePort。修复后 CPU 占用降低 40%，崩溃率下降 60%。
- 如何调试进程间的通信问题？
- 渲染进程崩溃后如何自动恢复？
- 有没有遇到过内存泄漏？如何定位？
contextIsolation: false 的安全风险；主进程频繁创建/销毁窗口会导致内存泄漏，需使用 windowTracker 统一管理生命周期。
项目案例：企业级协同办公桌面客户端
- 大数据量文档渲染性能优化
- 多窗口间状态实时同步
- 进程崩溃自动恢复与数据持久化
- 如何设计多窗口状态同步方案？
- 进程崩溃后如何恢复会话？
- 大数据量文档如何保证渲染不卡顿？
“通过主进程维护全局状态树，渲染进程通过 IPC 订阅状态变更；高频数据同步使用 SharedArrayBuffer，UI 更新经 requestAnimationFrame 节流。进程崩溃由主进程监听 child-process 退出事件，自动重建窗口并恢复会话。” 此方案核心优势是状态集中管理，避免窗口间不一致。
windowTracker 统一管理窗口生命周期” 和 “通过 crashReporter 收集崩溃上下文” 会体现工程化思维。