很多开发者的电脑里最后都会跑起来一两个用 Electron 做的桌面软件。我最初接触这个方向的时候是公司内部要做一个给多人协作用的资料批注工具传统网页在浏览器里做用户总觉得“差点意思”打开本地文件、拖拽外部素材、系统托盘提醒这些能力浏览器给得很别扭。于是我们换了思路用 Electron 把前端页面包装成一个真正的桌面程序短短几天就有了可以发给同事试用的版本。这篇博文就围绕“Electron 实现桌面应用”这件事从架构原理、项目搭建、进程通信、打包分发一直到常见坑位把我实际操作过的经验完整梳理一遍给之后要选型或正在填坑的人一个可以参考的路线。1. 为什么是 Electron 而不是其他方案1.1 桌面应用最常见的三条技术路线做桌面应用最传统的路子是用原生语言直接写界面比如用 C 配合 Qt、用 C# 做 WinForms/WPF或者用 Swift 写 macOS 上的原生程序。这条路线的问题显而易见你得为每个操作系统维护一套独立代码Windows 上能跑的程序到了 macOS 上基本不能用需要重写界面逻辑。团队里如果没有专门的原生开发人员这种方案的研发成本和维护成本都非常高一个很小的功能改动往往要分别走一遍编译、提测、发布流程。第二条路线是做一个纯网页应用用户打开浏览器地址就能用。这种方案的部署和迭代速度非常快前端同学的技术栈可以直接复用绝大多数业务功能都能在浏览器里完成。但它的边界也很明显浏览器出于安全考虑限制了对本地文件系统、系统级通知、全局快捷键、托盘图标等能力的深度调用即使用户要求“把网页做成可安装的桌面应用”浏览器提供的壳还是太弱交互体验也做不到桌面软件的流畅感。第三条路线就是先用 Web 技术写完整个界面和业务逻辑再用一个运行时外壳把它包装成桌面程序。Electron 就是这个外壳里目前生态最成熟的一个实现。它把 Chromium 浏览器内核和 Node.js 运行时打包在一起让前端代码可以调用 Node 能力也可以跟操作系统原生模块通信。对我这种以 Web 技术为主的团队来说这意味着大多数业务界面仍然用 HTML/CSS/JS 写UI 组件库、构建工具、测试体系全都可以原封不动地搬过来同时又能获得桌面应用的本地能力。1.2 Electron 解决的不只是“跨平台”这一个问题很多人提到 Electron第一反应是“跨平台”。但实际使用下来我觉得它的价值更多在于降低了桌面应用的工程化门槛。把你熟知的页面用 BrowserWindow 一包再通过主进程接入系统能力这个过程几乎不要求你会任何原生编程。应用的更新也变成了“替换前端资源”这种容易自动化的操作。普通的前端同学只要稍微了解一下 Node.js看几份文档就能独立完成一个曾经需要原生团队负责的产品形态。从生态角度看Electron 的社区沉淀已经很丰富。常用的界面需求可以靠前端生态解决本地数据存储可以用 electron-store 或者直接操作 SQLite自动更新有 electron-updater打包发布有 electron-builder 和 electron-forge。很多时候你要做的不是“发明新能力”而是从已有的工具里选一条合适组合。对于中小团队或者个人开发者这意味着能用有限的精力实现一个功能完整、体验接近原生的桌面应用。1.3 也要提前看到的代价Electron 并不是没有代价。它把 Chromium 内核、Node.js 运行时和你的应用资源打包在一起会导致安装包体积普遍偏大、内存占用相对较高。一个简单的桌面工具安装包可能超过 60MB运行内存轻松超过 150MB这是它的工作原理决定的。如果产品定位是“极简、轻量、低资源占用”的系统工具那么 Electron 方案也许并不是最优选择。另外应用启动时先要初始化 Chromium 和 Node 环境冷启动速度通常比同功能原生应用慢。我在接手内部工具时就明确和需求方确认过这类工具的使用场景是“常驻后台、频繁操作”不是“开机秒开”所以这点影响可以接受。做选型决策时先把用户对启动速度、内存占用的忍受程度搞清楚再决定要不要用 Electron而不是一上来就跟着潮流走。2. 从零搭一个最小可用的桌面应用2.1 环境准备与项目初始化开始之前这里假设你已经有 Node.js 环境。可以用 node -v 和 npm -v 两个命令确认版本Electron 在 Node 的常见 LTS 版本下都能正常安装。项目目录我用 demo-app 来做演示进入目录后执行 npm init -y生成一个默认的 package.json。接下来安装 Electron。安装时 npm 会拉取 Electron 的预编译二进制文件体积较大耐心等一会儿是正常的如果网络条件不太稳定安装过程可能会卡住重试或者手动配置镜像源都可以解决。安装完成后可以检查 node_modules/electron/dist 目录是否生成了对应的可执行文件。项目里依赖只需要装一个 electron后续运行都会基于它。package.json 里有两个配置项要特别注意。一个是 main 字段它告诉 Electron 启动后要加载哪个 JavaScript 文件作为主进程入口这里我填 main.js。另一个是 scripts.start把它设置为 electron .这样我们就可以用 npm start 来启动应用。没有 main 字段或者入口文件路径不对程序会直接报错退出。2.2 主进程文件 main.js 的完整结构Electron 应用启动后首先运行的是主进程它负责创建窗口、管理系统事件、处理窗口生命周期和与操作系统的交互。所以 main.js 不能只是一个简单的 JS 文件它需要引入 app 和 BrowserWindow 这两个核心模块。app 控制应用整体生命周期BrowserWindow 负责创建和操作浏览器窗口。一个能跑起来的最小 main.js 是这样的const { app, BrowserWindow } require(electron); const path require(path); function createWindow() { const win new BrowserWindow({ width: 1024, height: 768, webPreferences: { preload: path.join(__dirname, preload.js), contextIsolation: true, nodeIntegration: false, sandbox: true, }, }); win.loadFile(index.html); } app.whenReady().then(() { createWindow(); app.on(activate, () { if (BrowserWindow.getAllWindows().length 0) { createWindow(); } }); }); app.on(window-all-closed, () { if (process.platform ! darwin) { app.quit(); } });这段代码有几个关键点值得展开解释。webPreferences 里的 preload 指定了一个预加载脚本页面在加载任何代码之前就会执行这个脚本它是后续渲染进程和主进程安全通信的桥梁。contextIsolation 设为 true意味着渲染页面里的 JS 运行在一个独立上下文里不能直接访问 Node 的 process 等对象nodeIntegration 设为 false禁止页面直接使用 require。这两个配置是 Electron 安全模型的基础我会在下一节详细展开。window-all-closed 事件处理了关闭窗口时的行为。在 macOS 上关掉所有窗口不代表退出应用用户通常会再次点击 Dock 图标唤起应用所以当平台是 darwin 时不能直接退出。在 Windows 和 Linux 上关闭所有窗口就退出应用。activate 事件是 macOS 特有的点击 Dock 图标且当前没有窗口时重新创建一个窗口。如果不写这段应用在 macOS 上的表现就会很别扭。2.3 渲染层和预加载脚本渲染层就是我们熟悉的网页页面。在项目下新建 index.html放一个基础页面内容用于展示应用版本和运行状态!DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta http-equivContent-Security-Policy contentdefault-src self; script-src self / titleElectron 示例应用/title /head body h1桌面应用已启动/h1 p idversion正在读取版本信息.../p script src./renderer.js/script /body /html再创建一个 preload.js用 contextBridge 把主进程的能力安全地暴露给页面const { contextBridge, ipcRenderer } require(electron); contextBridge.exposeInMainWorld(api, { getVersion: () ipcRenderer.invoke(get-version), });renderer.js 里这样调用window.api.getVersion().then((version) { document.getElementById(version).textContent Electron 版本${version}; });页面里的脚本没有直接使用 require它调用的 window.api 是 preload 脚本注入到全局对象上的。这种间接调用的好处是即使页面代码被注入恶意脚本也无法直接拿到 Electron 底层的全部能力只能调用你明确暴露出来的方法。这种设计不是麻烦自己而是必须遵守的底线。2.4 启动应用并观察运行效果在项目目录下执行 npm start正常情况下会弹出一个桌面窗口窗口大小为 1024x768页面内容正常渲染版本信息里会显示当前 Electron 的版本号。到这里一个最小的桌面应用就跑通了。Electron 在开发模式下提供了丰富的调试能力。在页面里按 F12 可以直接打开 DevTools它能调试渲染进程里的 DOM、网络请求和控制台日志。主进程的日志则会输出到启动应用的终端窗口里。实际开发中我习惯在启动脚本里增加 --enable-logging 参数这样可以把渲染进程的 console 日志也输出到终端排查问题会方便很多。3. 主进程、渲染进程与通信机制3.1 进程模型的多层含义Electron 的架构里面主进程和渲染进程之间的关系可以这样理解主进程是应用的总管家负责创建窗口、跟操作系统交互、管理菜单和托盘渲染进程是每个窗口里的页面环境负责显示界面和响应用户操作。一个应用可以有一个主进程却可以同时有多个渲染进程每个 BrowserWindow 默认对应一个独立的渲染进程。这种分离不只是工程组织问题更是一个安全边界。想象一下如果渲染进程页面里可以随时使用 require 读取用户文件那么一但页面加载了任何前端脚本攻击者就有机会访问本地磁盘。默认不让 nodeIntegration 直接开启、让 preload 作为受限的“外交官”本质是在控制风险面。主进程拥有完全权限渲染进程尽可能只接触页面环境两者通过消息机制互相协作。主进程和渲染进程的分工差异还会影响你的开发习惯。比如系统托盘、全局快捷键、窗口控制这些事情必须在主进程做而 DOM 操作、页面动画、表单交互则毫无疑问属于渲染进程。业务数据在主进程和渲染进程之间的传递不能靠共享全局变量必须走消息通道因为它们是两个完全隔离的运行环境。3.2 用 IPC 实现请求和响应式通信Electron 提供了一组标准的 IPC 机制。最常用、也最符合直觉的是 ipcRenderer.invoke 加 ipcMain.handle 的组合。渲染进程发起请求主进程处理并返回结果。上一节代码里的 getVersion 就是一个最小示例。我直接在 main.js 里注册处理逻辑const { app, BrowserWindow, ipcMain } require(electron); ipcMain.handle(get-version, () { return process.versions.electron; });当渲染进程执行 window.api.getVersion() 时它会通过 preload 暴露的方法向主进程发送一条名为 get-version 的消息主进程对应的 handle 函数执行完返回值再传回渲染进程。整个过程对页面里的业务代码几乎是透明的和调用一个 Promise 方法没有区别。除了请求响应模式还有一种主动推送模式。主进程在某些时机需要主动给渲染进程发消息比如后台完成了一个耗时任务、下载进度发生变化这时候可以用 webContents.sendipcMain.handle(start-task, (event) { const win BrowserWindow.fromWebContents(event.sender); let progress 0; const timer setInterval(() { progress 10; win.webContents.send(task-progress, progress); if (progress 100) { clearInterval(timer); } }, 200); return started; });渲染进程一侧通过 ipcRenderer.on 监听消息。为了把这种监听能力安全地暴露给页面preload 里可以封装成订阅方法const { contextBridge, ipcRenderer } require(electron); contextBridge.exposeInMainWorld(api, { startTask: () ipcRenderer.invoke(start-task), onTaskProgress: (callback) { ipcRenderer.on(task-progress, (_event, progress) callback(progress)); }, });在页面业务里组件挂载时可以订阅进度回调组件卸载时要记得取消订阅。IPC 订阅如果不清理会变成一种内存泄漏的来源窗口关闭后消息还在往不存在的回调函数里发。处理办法是在窗口 close 事件里统一清理或者在暴露订阅方法时返回一个取消函数。3.3 安全通信的正确姿势我在文章里反复强调 preload 和 contextIsolation是因为这些细节直接决定应用的安全基线。官方文档早就建议关闭 nodeIntegration、开启 contextIsolation 并用 preload 暴露白名单 API。我刚入门那会儿图方便直接开启 nodeIntegration页面里也能用 require开发时确实很爽但哪怕只是加载了一个来自远程地址的图片只要该内容包含可执行脚本它就有机会访问 Node 接口。这个风险不能赌。再一个容易忽略的点是 Content-Security-Policy。我在 index.html 的 meta 标签里设置 default-src self就是告诉页面“资源只能从当前应用内部加载”。如果你的应用需要访问远程接口需要按实际需求放行 connect-src。设置 CSP 可以明显降低 XSS 导致的危害范围虽然它不能完全替代干净的输入输出检查但能给应用多一层保护。preload 脚本的上下文也是一个需要留意的细节。contextIsolation 开启时preload 和页面共享 DOM但 JS 全局对象是隔离的。preload 里不能直接给 window 挂函数必须用 contextBridge.exposeInMainWorld。暴露 API 时尽量避免把所有 ipcRenderer 方法透传出去宁可一个一个列出你允许页面调用的方法也不要图省事暴露全部通信能力。3.4 窗口之间的层级和通信实际应用中一个桌面工具很少只有一个窗口。次级窗口、弹窗、设置页面这些东西很常见。主窗口可以创建一个 child BrowserWindow 并把父窗口传给它这样子窗口默认会居中显示在父窗口上方关闭父窗口时子窗口也会一起处理。function openSettingsWindow(parentWin) { const child new BrowserWindow({ parent: parentWin, width: 600, height: 400, webPreferences: { preload: path.join(__dirname, preload.js), contextIsolation: true, nodeIntegration: false, sandbox: true, }, }); child.loadFile(settings.html); }子窗口里的页面如果想读取主窗口的状态最简单的做法是继续通过 IPC 请求主进程由主进程统一返回数据。不要让页面之间直接尝试互相访问那样既绕远又容易踩到跨窗口安全限制。窗口管理逻辑集中在主进程会让整个应用的数据流向更容易梳理。4. 打包与分发把项目变成能发的安装包4.1 打包工具选 electron-builder开发阶段的应用依赖 npm start 启动没有经历过打包流程的人可能觉得“这东西不就是一个网页壳子吗”。但实际要发布给别人使用时打包是把 Electron 运行时、应用代码、资源文件组装成一个可执行安装包的过程。目前社区最常用、我也一直在用的是 electron-builder它对 Windows、macOS、Linux 都有现成的目标支持。先把 electron-builder 作为开发依赖安装然后在 package.json 里增加 build 配置。一个贴近真实项目的配置大致是这样的{ name: demo-app, version: 1.0.0, description: 示例桌面应用, main: main.js, scripts: { start: electron ., dist: electron-builder }, build: { appId: com.example.demoapp, productName: 示例应用, directories: { output: release }, files: [ main.js, preload.js, renderer.js, index.html, assets/**/* ], win: { target: [nsis] }, nsis: { oneClick: false, allowToChangeInstallationDirectory: true, createDesktopShortcut: true }, mac: { target: [dmg], category: public.app-category.productivity }, linux: { target: [AppImage], category: Utility } } }最核心的配置是 files 字段它决定了哪些文件会被打包进应用。默认情况下electron-builder 会把项目里的大部分文件都带上但如果你的项目里存在源代码、测试文件、临时缓存这些不必要的内容把它们排除在外可以让应用包更干净。我通常在 files 里明确列出应用运行需要的最小文件集合而不是依赖默认的打包过滤规则。4.2 跨平台打包的重点差异在 Windows 上nsis 目标会把应用打成一个标准的安装程序。nsis 配置里的 oneClick: false 可以让用户选择安装目录对很多企业内部工具来说这个配置很必要。allowToChangeInstallationDirectory 配合使用允许用户把应用安装到非默认目录。在 macOS 上dmg 目标会生成一个磁盘镜像文件。macOS 对应用签名和公证的要求很严格没有正确签名和公证的应用用户第一次打开时可能会被系统拦截。这个流程涉及开发者证书、公证凭证等环节整个配置会复杂一些。个人开发者如果只是内部试用至少也要在用户打开时给出右键“打开”的说明否则会让使用者觉得软件不可信。Linux 上 AppImage 是最常见的目标它不需要用户真正“安装”下载下来添加执行权限就能运行。需要注意 Linux 发行版非常多库依赖各有不同AppImage 已经是一个相对通用的格式但仍可能在某些精简发行版上缺少共享库。如果目标用户比较固定也可以额外打 deb 或 rpm 包。4.3 自动更新设计软件产品一旦分发出安装包版本管理就成了日常运维问题。没有自动更新每次修改一个 bug 都要让用户重新下载安装这在体验上是灾难性的。electron-updater 是配合 electron-builder 常用的更新方案。打包完成后它会在应用目录生成 latest.yml 之类的元数据文件客户端可以通过这些元数据判断服务器上是否有新版本。配置自动更新需要约定一个更新服务器的地址。electron-updater 的 generic 提供商很适合自建静态资源服务器只要我们保证发布目录里有新版本的安装包和对应的元数据文件即可。更新流程设计上要有三个状态检查更新、下载进度、提示重启。下载和校验的过程应该在应用后台完成不要让用户等待白屏。实际部署中我还要做一层校验只有安装包签名或哈希校验通过才能执行更新操作避免中间人篡改。4.4 安装包体积与 asar 机制打包后的应用会占用较大的磁盘空间这是 Electron 的固有特性。但至少我们可以把应用自身资源压缩进一个 asar 文件减少散文件的数量提高文件读取效率。electron-builder 默认会把应用代码打包成 app.asar安装目录里看到的是一堆二进制文件加一个 asar而不是源 JS 全部裸露在外。asar 文件不是加密只是归档格式有工具可以解开查看里面内容。如果应用里有比较敏感的密钥、算法逻辑不要指望依靠 asar 保护真正的敏感数据应该放在运行时由服务端动态下发或者至少做混淆与加固。这个认知很重要很多团队以为打包后代码就是安全的其实只是防止了普通用户直接翻目录而已。5. 真实功能落地时的常用模块与性能优化5.1 系统托盘和全局快捷键办公工具类桌面应用几乎都少不了一个系统托盘图标。用户关掉窗口后应用不退出而是在右下角或者顶栏菜单栏显示一个小图标点击可以弹出操作菜单。实现托盘基本不需要太多代码但有一个容易踩坑的点托盘图标要使用合适尺寸的图片资源Windows 上建议用 ico 或者 32x32 的 pngmacOS 上可以准备一组适配深色模式的 template 图片。直接用大的彩色图在浅色和深色系统主题下会很难看。全局快捷键是用来在应用不处于前台时也能触发操作的比如截图工具按一个组合键就启动圈选。globalShortcut.register 一旦注册成功会在系统全局生效。我建议把快捷键做成可配置项注册前先检测是否被其他应用占用避免冲突并在应用退出时统一 unregister。const { app, globalShortcut, Tray, Menu } require(electron); let tray null; app.whenReady().then(() { tray new Tray(path.join(__dirname, assets, tray.png)); const contextMenu Menu.buildFromTemplate([ { label: 显示主窗口, click: () { /* 找回主窗口 */ } }, { label: 退出, click: () app.quit() }, ]); tray.setToolTip(示例应用); tray.setContextMenu(contextMenu); const registered globalShortcut.register(CommandOrControlShiftD, () { /* 触发某个操作 */ }); if (!registered) { console.warn(快捷键注册失败可能被其他应用占用); } }); app.on(will-quit, () { globalShortcut.unregisterAll(); });5.2 本地数据持久化方案选择桌面应用通常需要保存用户偏好设置或者业务数据。最简单的方式是直接写 JSON 文件到用户数据目录通过 app.getPath(userData) 获取当前系统下应用专属的数据目录。这种方式适合配置比较少、结构简单的场景。我早期做过的一个小工具就只保存窗口位置和用户选项JSON 文件完全够用。如果数据量增加或者需要做复杂查询electron-store 是个不错的封装它内部还是 JSON 文件但提供了更友好的读写 API。数据量更大、需要多表关联时推荐在 Node 侧使用 better-sqlite3 这类同步 SQLite 库。SQLite 文件同样可以放在 userData 目录不需要启动额外数据库服务。选型原则是能用一个文件解决的数据不要先上重型数据库。无论是 JSON 还是 SQLite写入操作都要考虑磁盘 IO 的时机。不要每次用户操作都同步写文件更合理的做法是收集变更后防抖写入。大量中断写入可能造成文件损坏定期备份数据文件的机制也值得考虑。5.3 调用本机文件、命令和系统能力Electron 主进程可以通过 dialog 模块打开系统文件选择框读取文件内容后返回给渲染进程展示。比如一个本地化工具需要让用户选择一批图片可以这样弹窗const { dialog, ipcMain } require(electron); ipcMain.handle(select-images, async () { const result await dialog.showOpenDialog({ properties: [openFile, multiSelections], filters: [ { name: Images, extensions: [png, jpg, jpeg, gif] }, ], }); return result.filePaths; });这种能力虽然方便但也意味着渲染进程可以触发文件访问。我强烈建议把“哪些路径可以被读取”这个决策逻辑放在主进程里渲染进程只负责告诉主进程“用户想选文件”这个意图。不要让渲染进程把任意文件路径直接传给 Node 侧去读取否则一旦页面被注入脚本文件数据就可能泄露。必要的时候用 path 模块校验目标路径是否在允许的目录范围内坚持做“白名单”访问。5.4 渲染进程性能优化与内存管理Electron 应用性能问题的源头很大程度来自“每个窗口都是一个 Chromium 实例”这一点。优化思路可以围绕四个方面。第一减少窗口数量。很多后台业务根本不需要独立窗口用页面内某个 div 或 webContents 支持的新窗口模式比如用 BrowserView 或者 WebContentsView会比分出多个完整 BrowserWindow 更省资源。第二避免主进程直接做耗时的同步操作。CPU 密集型、大文件解析都应该使用 Node 的 worker_threads 子进程处理处理完成后通过 IPC 将结果回传。第三应用启动时不要加载大量无关页面可以等窗口 onReady 之后按需加载资源。第四管理好 window.api 订阅等事件监听器窗口关闭时清掉监听器避免循环引用导致内存不释放。一个容易忽视的点是Electron 应用即使主窗口被关闭有些子进程或定时器还可能在后台运行造成 CPU 占用。开发时可以通过任务管理器观察是否有异常进程也可以在应用代码里对定时器做统一清理。调试内存泄漏时可以用 DevTools 里 Performance 面板和 Memory 面板分析堆快照先定位到“哪个对象一直增长”再考虑怎么释放。6. 常见问题速查与一线开发心得6.1 高频问题对照表以下是我在实际开发和帮同事排查过程中经常遇到的问题整理成一张速查表遇到对应症状可以快速定位方向。现象常见原因处理思路应用启动后窗口白屏页面资源路径错误loadFile 加载不到文件检查相对路径优先用 path.join(__dirname, ...) 拼接绝对路径页面提示 require is not definednodeIntegration 被关闭页面代码里还在用 require业务逻辑不应该直接 require改为 preload 暴露 API打开 DevTools 才能看到 console 日志渲染进程日志默认不输出到终端启动命令加 --enable-logging或者监听 console-message 事件点击关闭窗口但进程不退出window-all-closed 处理逻辑遗漏确认 process.platform 判断Windows/Linux 应调用 app.quit()局域网内收不到更新更新服务器地址配置错误或资源未同步元数据检查 latest.yml 是否在服务器正确位置再核对 provider 配置打包后体积异常大files 配置过宽把源码和测试文件都打进去了精简 files 白名单排除无关目录安装包被杀毒软件提示风险Electron 应用没有签名行为特征像未知程序Windows 尽量做代码签名企业内部可通过白名单方式处理使用 SQLite 时数据文件被占用多窗口同时访问同一数据库文件数据库操作统一收敛到主进程避免多个渲染进程直接并发连接托盘图标在深色模式下看不清图标不是 template 图片或没有 alpha 通道macOS 上准备 template iconWindows 使用合适像素的 ico 文件应用启动速度很慢启动时加载了过多窗口模块或执行了耗时初始化延迟初始化非必要模块优先渲染窗口数据准备好后再填充表格只是定位线索真正修复问题还要根据具体代码路径去分析。但多数 Electron 问题最后都指向同一个根因进程边界没理清或者安全配置不收敛。6.2 把 Web 项目迁移进 Electron 时的思路不少团队选择 Electron 是为了把已有的 Web 系统包装成桌面版。这个过程看起来简单但直接套壳会有很多细节要考虑。首先项目的资源路径要是相对路径否则用 file:// 协议加载时会找不到资源。其次本地页面默认处于离线状态如果原 Web 项目依赖 CDN 脚本迁移前要把这些资源本地化或者构建时统一打包。遇到跨域请求这类浏览器限制时可以借助主进程发起网络请求再通过 IPC 结果返回绕开渲染进程的 CORS 限制。逻辑层代码要尽量保证平台无关。比如之前用 window.localStorage 存储偏好设置迁移到 Electron 后仍然可以工作但如果你想跨窗口共享这份配置最好改为基于文件的持久化方案。还有文件下载逻辑浏览器版通常是触发一个下载由浏览器默认下载器来处理桌面版则需要明确下载保存路径、显示进度条并把下载状态和界面状态关联起来。6.3 团队协作中的工程化经验Electron 项目表面上是“前端项目”但工程纪律上比普通 Web 项目要更高。代码里涉及主进程、preload、渲染进程三个区域的 JS它们各自的可访问权限完全不同。我习惯在目录里把这三个区域明确分开例如 main/、preload/、renderer/并配好 eslint 环境preload 和 main 使用 Node 环境renderer 使用浏览器环境。这样静态检查就能在开发早期拦住不少滥用全局对象的代码。版本管理上Electron 依赖高版本频率较快锁定大版本区间是有必要的。Electron 的大版本升级通常伴随 Chromium 版本升级可能带来渲染行为变化。上线前最好准备一份基本功能回归清单跑一遍主要流程再升级。依赖变化对项目的影响不比业务代码bug小。最后是发布流程。我是这样设计的本地执行构建脚本生成安装包同时生成对应版本的哈希文件这两个文件上传到更新静态目录然后更新元数据 JSON。客户端启动时主动检查版本发现新版本就提示用户更新。这个链路虽然不算复杂但每环都要有日志否则线上出现“用户看到旧版本”的问题时很难定位是网络原因还是配置原因。在实际项目里踩过坑之后的几点体会我带过一个客制化工具项目最初某同事直接用前端那套“页面加载完成就一切搞定”的思路写 main.js连 nodeIntegration 都忘了关发布前做安全检查时才发现页面引用的一个统计脚本如果被劫持就能直接读用户目录文件。后来我们统一把 nodeIntegration 关掉、用 preload 暴露需要的 API安全基线才算真正落地。每次给新加入项目的人都强调同一个原则渲染进程里没有任何东西是绝对可靠的所有本地能力调用必须在主进程做白名单校验。还有一次因为图标资源用了大尺寸 png在 macOS 底栏上显示得又大又糊用户反馈“很业余”我们换成 template 图标后才恢复正常。这类细节问题看似小却能直接影响别人对产品质量的第一印象做桌面应用时不要把这些问题留在最后再处理。再分享一个小经验不要一上来就想做超复杂架构。Electron 已经包含了 Chromium 和 Node.js 两套运行时足够支撑大部分业务如果你的需求还没有发展到需要多个窗口同时存在、大量后台并发任务、复杂自动更新策略的阶段那就保持简单的“一个主进程、一个窗口、通过 IPC 通信”结构。架构清晰比架构宏大重要得多后续扩展时再逐步引入更复杂的模块也不迟。这套技术路径我已经验证过很多次照着这个思路去搭应用一开始慢一点后面会顺很多。
