Electron 架构怎么定：按项目规模选模块化方案的完整做法

Electron 架构怎么定按项目规模选模块化方案的完整做法【免费下载链接】electron:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS项目地址: https://gitcode.com/GitHub_Trending/el/electronElectron 应用做到两三万行之后最常见的状况是窗口逻辑、业务状态、IPC 消息全挤在同一个入口文件里每次加功能都要通读一遍主进程代码才敢动手。这篇内容直接给出三样东西不同规模项目该选哪种架构的判断表、进程边界与 Context Bridge 这套核心机制的拆解以及可以直接照抄的目录划分、依赖治理和性能手段。先定架构按项目规模选而不是先学模式 先回答选哪种再展开怎么实现。判断依据是代码量、窗口数量和团队协作方式对照下面这张表即可定位项目特征推荐架构目录形态进程通信方式单窗口、个人项目、5k 行以内单体内分区main、renderer 各一个目录直接 ipcRenderer.invoke无需封装多窗口、2~5 人、3w 行以内水平分层 按功能拆模块main / renderer / common 三层功能在层内纵向切每个功能模块自定义通道前缀十万行级、多团队壳应用 微应用shell 管窗口与导航各业务独立构建模块只与壳通信禁止模块互调规则只有一条规模不够别上重型结构。给个人工具引入微前端维护成本比代码本身还贵反过来十万行的应用还靠一个入口文件撑任何人都不敢动第二行。机制深挖进程边界是 Electron 架构的地基Electron 的架构问题几乎都出在进程边界的模糊上。主进程单实例存在独占 app 生命周期、窗口管理、菜单、系统通知这类原生能力渲染进程则按页面数量多开只负责 UI 与页面逻辑。判断一段代码该放哪边就看它是否需要操作系统级资源——需要归主进程不需要归渲染进程。Electron 本身就是这么约束的主进程能用的模块和预加载脚本能用的模块是两份完全不同的清单。主进程模块清单里登记了 app、BrowserWindow、ipcMain、Menu、utilityProcess 等几十项全部是单例级的系统能力而 预加载模块清单只有 contextBridge、ipcRenderer、nativeImage 三项。这份刻意收窄的白名单等于替每个项目提前划好了进程边界的底线渲染侧永远拿不到 Node 的系统 API一切能力必须过桥。Context Bridge渲染侧唯一合法的取数通道结论先行页面代码不应该认识 ipcRenderer只应该认识 preload 里暴露出来的那组函数。Electron 仓库里的实现lib/renderer/api/context-bridge.ts在暴露 API 前会强制校验 contextIsolation 是否开启隔离没开就不让调用。使用时保持窄暴露原则// preload.js const { contextBridge, ipcRenderer } require(electron) contextBridge.exposeInMainWorld(appApi, { getUser: (id) ipcRenderer.invoke(user:get, id) })// 主进程 const { ipcMain } require(electron) ipcMain.handle(user:get, (_event, id) userService.fetch(id)) // 页面侧 const user await window.appApi.getUser(1)为什么必须这么写invoke/handle 是请求响应配对天然带返回值和错误处理适合所有读操作暴露的函数签名即页面 API后续改实现不影响 UI 层。反模式是把整个 ipcRenderer 塞进 window或者在 preload 里写通用代理转发任意通道——后者等于把白名单机制整个拆掉。三种架构形态跟着规模递进讲小型一个目录解决的事不要拆两个。主进程入口、preload、页面代码各归其位即可IPC 通道名用功能:动作的命名习惯如window:minimize防止日后乱撞。此阶段的架构决策只有两个开不开 contextIsolation开要不要封装 IPC不要。中型分层与功能切分并行。水平方向分三层——main 放窗口和生命周期renderer 放 UI 与状态common 放两边都要用的常量、类型、工具函数Electron 源码里的 common 模块 就是跨进程共享代码的现成范例。垂直方向按功能切模块每个业务模块内部再分自己的主进程代码、渲染端代码和共享类型并只通过模块的 index 出口对外模块间不允许直接 import 内部文件。这样改登录不影响编辑器就有了物理保障。超大型壳应用 微应用。窗口创建、路由、系统托盘收进 shell仪表盘、编辑器、设置等拆成独立构建、独立部署的子应用各自维护自己的 preload 与更新节奏。关键纪律是微应用之间不直接通信所有跨模块调用走壳的 IPC 通道中转。这牺牲了一点调用效率换来的是任何业务模块崩溃或下线都不波及全局——这个代价只有多团队协作时才划算。工程落地目录、依赖、性能一次说清Electron 主进程目录怎么划分。以进程为第一级目录main / renderer / common功能为第二级入口文件 main.ts 只做三件事初始化、注册 IPC 总表、创建窗口。业务逻辑下沉到 services 与 ipc 两个子目录前者管数据与副作用后者只做参数校验与转发。common 目录只允许纯函数与类型禁止出现任何require(electron)。依赖关系怎么管。出现循环依赖的信号是构建报错或模块加载时拿到 undefined解法是引入事件总线或中介者A 不再 import B而是监听 B 发出的事件。重计算任务转码、索引、大批量解析挪到 utilityProcess 跑utilityProcess 源码 里可以看到它本质上就是开了一个独立的 Node 子进程主进程不陪跑、渲染进程不卡顿。性能手段怎么选。三个手段按优先级排大模块动态 import菜单、设置面板这类低频功能延迟到触发时才加载关键资源随应用启动预载复杂页面拆到独立视图进程隔离渲染避免一个标签页卡死整个窗口。顺序别反——先确认模块划分正确再谈加载时机优化否则动态 import 只是给混乱的代码换了个出场方式。避坑清单与源码入口坑后果正确做法IPC 传函数或 DOM 对象结构化克隆直接报错只传可序列化的纯数据为图方便关掉 contextIsolation页面可直达 Node API安全模型崩塌保持开启能力一律走桥preload 顶层写异步初始化时序竞争API 偶发 undefined异步逻辑放进暴露的方法内部模块间横向 import 内部文件改 A 连带崩 B只暴露 index 出口主进程同步阻塞大量文件 IO 等所有窗口 UI 冻结阻塞操作挪到 utilityProcess 或 child_process想继续往源码里挖三个入口够用进程模型的完整说明在 docs/tutorial/process-model.md安全侧的上下文隔离原理在 docs/tutorial/context-isolation.md主进程到底有哪些原生模块则直接翻 lib/browser/api/module-list.ts。文中涉及的模块清单与接口行为均以 Electron 官方仓库源码为准不同版本间预加载白名单和视图 API 可能有差异落地前建议对照所用版本核对一遍。【免费下载链接】electron:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS项目地址: https://gitcode.com/GitHub_Trending/el/electron创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考