企业官网建设流程全解析

很多开发者的电脑里，最后都会跑起来一两个用 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 lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'" /> <title>Electron 示例应用</title> </head> <body> <h1>桌面应用已启动</h1> <p id="version">正在读取版本信息...</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.send：

ipcMain.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 的 png，macOS 上可以准备一组适配深色模式的 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('CommandOrControl+Shift+D', () => { /* 触发某个操作 */ }); 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 高频问题对照表

以下是我在实际开发和帮同事排查过程中经常遇到的问题，整理成一张速查表，遇到对应症状可以快速定位方向。

表格只是定位线索，真正修复问题还要根据具体代码路径去分析。但多数 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 通信”结构。架构清晰比架构宏大重要得多，后续扩展时再逐步引入更复杂的模块也不迟。这套技术路径我已经验证过很多次，照着这个思路去搭应用，一开始慢一点，后面会顺很多。