Electron 应用中主进程与渲染进程必须通过 IPC 通信：主进程管理窗口和系统 API，渲染进程负责 UI；使用 ipcMain 和 ipcRenderer 配合 invoke/handle 实现安全双向通信，推荐通过 preload.js 暴露受限 API。
Electron 应用里，主进程和渲染进程是两个独立运行、彼此隔离的环境，它们不能直接共享变量或调用函数。通信必须通过明确的、受控的通道完成——核心就是 IPC（Inter-Process Communication）机制。理解清楚这个机制，是写出稳定、安全、可维护 Electron 应用的关键。
主进程与渲染进程的角色分工要先搞清
主进程（通常由 main.js 启动）负责创建窗口、管理应用生命周期、访问操作系统 API（如文件系统、托盘、菜单等）。它运行在 Node.js 环境中，拥有完整权限。
渲染进程（每个 BrowserWindow 对应一个）本质是 Chromium 浏览器页，运行在 Web 环境中，默认禁用 Node.js 集成（出于安全考虑），只负责 UI 渲染和用户交互。
二者不共享内存，也不共用全局对象。想让“点击按钮后保存文件”，就得靠 IPC 搭桥：渲染进程发请求 → 主进程收消息 → 执行操作 → 再把结果发回去。
两种 IPC 通道：ipcMain + ipcRenderer 是标配组合
Electron 提供一对配套 API 实现双向通信：
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 主进程监听用 ipcMain.on()：注册事件名，等待渲染进程发送消息。支持同步（handle()）和异步（on()）两种响应方式
- 渲染进程发送用 ipcRenderer.send() 或 invoke()：前者发异步消息（无返回值），后者发异步请求并等待 Promise 返回结果（推荐用于需响应的场景）
注意：渲染进程默认无法直接 require('electron')，需在 webPreferences 中显式开启 contextIsolation: false 和 nodeIntegration: true（不推荐）；更安全的做法是通过 preload.js 暴露有限、受控的 API 给渲染进程使用。
preload.js 是安全通信的枢纽
它是在渲染进程加载页面前执行的脚本，运行在主进程与渲染进程之间的“中间层”：既能访问 Node.js（通过 contextBridge），又能向 window 注入 API，但不会暴露整个 Electron 或 Node 对象。
典型写法示例：
const { contextBridge, ipcRenderer } = require('electron')
contextBridge.exposeInMainWorld('api', {
saveFile: (content) => ipcRenderer.invoke('save-file', content),
onOpen: (callback) => ipcRenderer.on('file-opened', callback)
})
这样，渲染进程里就能安全调用 window.api.saveFile(...)，而无需暴露 ipcRenderer 全局对象。
常见通信模式与避坑提醒
- 单次请求-响应：用 invoke()/handle()，适合读取配置、保存数据、打开文件等有明确返回的场景
- 事件通知（无返回）：用 send()/on()，适合主进程主动推送（如更新检查、系统通知）或简单触发动作（如关闭窗口）
- 避免跨进程传大对象：JSON 序列化有性能开销，且 V8 传输限制约 1MB；大数据建议传路径或 ID，再由接收方自行读取
- 监听器记得清理：渲染进程用 on() 订阅事件后，在组件卸载或页面跳转时调用 removeListener()，否则可能引发内存泄漏或重复响应
基本上就这些。IPC 不复杂，但容易忽略安全边界和生命周期管理。理清谁该发、谁该收、怎么传、怎么收，主渲染协同自然就稳了。
