企业官网建设流程全解析

我想先聊一个很实在的事：当你接手一个“跨平台桌面应用程序”需求，团队里都是前端、工期又紧的时候，Electron基本上是唯一能把“不可能”变成“很麻烦但能交付”的方案。我最早接触Electron是因为一个内部数据录入工具，之前大家天天开着浏览器用网页端，一天误关几次标签页就烦躁得不行，后来实在忍不了，桌面版提上了日程。当时摆出来的候选方案不少，Qt、C#、JavaFX、Tauri都有，但最终我们还是选Electron，而且这之后连续做了好几个项目，踩了不少坑，也积累了不少经验。

这篇文章不是Electron官方文档的复述，而是我基于实际项目沉淀下来的总结，主要给两种人看：一是准备用Electron做跨平台桌面应用的开发者和技术负责人，想搞清楚这技术到底适不适合自己、选型理由是什么；二是已经上手Electron但遇到白屏、打包、更新、内存泄漏等头疼问题的人。我会把架构设计、工程搭建、打包发布、性能优化这些链路完整过一遍，并把那些“文档里不写、实际项目里一定会碰”的经验一并讲清楚。

1. 为什么选Electron：技术选型背后的问题与取舍

先说结论：Electron最适合的是“团队是Web技术栈、需要快速交付跨平台桌面客户端、并且对包体积和系统资源占用不是极端敏感”的项目。这句话听起来像和稀泥，但你把这几个约束拆开看，就会明白为什么我把话讲得这么严谨。

1.1 什么人适合用Electron，什么项目真不适合

我见过程序员朋友从后端转来做桌面工具，一上来就想用Qt，理由是“性能好、原生”。这个问题要分两面看：Qt性能确实好，运行一个空窗口内存占用能压得很低，但Qt的研发效率是一场灾难——C++或Python环境、信号槽和槽函数那一套、跨平台编译的坑，一个初学者光是把开发环境理顺就得一两周。团队如果在Web技术栈上有积累，Electron的学习曲线几乎是平缓的，TypeScript、React、Vue都能直接拿过来用，UI层交付速度非常快。

但也有明确不适合Electron的场景。比如你要做的是一个极其轻量的单文件小工具，期望安装包5MB以内、内存占用控制在30MB以下，那Electron确实做不到，单个可执行文件就100MB左右了。再比如你要做视频非线性编辑、3D建模这类重度依赖底层CPU/GPU算力和系统原生接口的软件，Electron就算调用了本地资源，仍然受限于Chromium的渲染管线与Node层交互的开销。判断标准很简单：你的核心诉求是“快速做出一套业务功能复杂的桌面客户端”，还是“极致优化每个字节的性能和资源”。

1.2 与Qt、Tauri、C#等方案的横向对比

我整理了一份常用方案对比，这个表格我做选型时也一直在用，到现在看了很多项目之后依然觉得没毛病。

从这个表能看出来，Electron真正的优势不是绝对性能，而是“用最熟悉的技术栈，以最快的速度覆盖macOS、Windows和Linux三个平台”。我曾经用一个内部项目算过一笔账：用Qt预估6个人做一个半月，最后交付时可能还有系统兼容问题；用Electron两个人三周就能做出一版可用的，后续迭代也都是前端节奏。在大多数商业场景下，这个速度差异比体积多出80MB要重要得多。

Tauri我看到越来越多人在推荐。它确实把包体积做下去了，但代价是后端要写Rust，团队里如果没有这方面积累，光是把系统API封装好就要额外花一倍时间。而且Tauri在Windows上调用系统能力时也经常需要写一层Rust代码，前端享受的“红利”在深水区会慢慢被抵消。我的判断是：Tauri适合早期就决定要重度定制的产品，而Electron适合“先以业务功能制胜、再考虑优化”的产品。两类产品没有高低之分，只有阶段和条件之别。

2. 进程模型没吃透，项目后面一定会翻车

我复盘过很多出问题的Electron项目，十有八九是没搞懂进程模型就开始写代码了。主进程、渲染进程、preload脚本、IPC通信——这四个概念如果只是停留在“知道名词”的层面，那么白屏、内存泄漏、安全漏洞、数据同步错乱这些问题都会在项目后期集中爆发，而且越修越乱。

2.1 主进程、渲染进程与Preload的关系

Electron至少会启动两类进程：主进程和渲染进程。主进程是应用的总管家，负责创建窗口、管理菜单、托盘、系统对话框，以及所有访达系统资源的能力；渲染进程就是我们熟悉的Chromium页面，负责画界面和处理用户交互。两者之间是隔离的，渲染进程不能直接读写本地文件，也不能直接调用Node.js API，这既是安全限制，也是设计边界。

很多人初学Electron时会看到一些老教程，教你在渲染进程里直接用require('child_process')、require('fs')，这在早期版本确实能用，因为当时的默认配置把nodeIntegration开成了true。但现代Electron已经把这种写法视为反面案例了：一旦渲染进程加载的页面里有任何不可信内容（哪怕是你自己的代码里有个XSS），攻击者就等于拿到了你的Node权限，直接读取本机文件，想象一下有多可怕。所以我自己写新项目时，一律把nodeIntegration: false，而用preload脚本在中间搭一座桥。

preload脚本跑在渲染进程之前，但它拥有部分Node能力，可以通过contextBridge安全地暴露白名单接口给页面。这里有一个我非常推荐的最小示例：

// preload.cjs const { contextBridge, ipcRenderer } = require('electron'); contextBridge.exposeInMainWorld('desktop', { getConfig: (key) => ipcRenderer.invoke('app:get-config', key), saveConfig: (key, value) => ipcRenderer.invoke('app:save-config', key, value) });

然后在主进程里：

// main.cjs const { app, BrowserWindow, ipcMain } = require('electron'); ipcMain.handle('app:get-config', async (event, key) => { // 在这里做实际的配置读取 return getConfigValue(key); }); ipcMain.handle('app:save-config', async (event, key, value) => { return persistConfigValue(key, value); });

为什么一定要这样走一遍？因为ipcRenderer.invoke这种调用方式是异步请求-响应模型，它天然地把“渲染进程发请求”和“主进程给结果”变成了两个清晰的动作，数据流是单向且可控的。页面里拿到的永远只是window.desktop这个对象上暴露的有限方法，就算页面被人注入脚本，对方也只能调用这几个方法，拿不到其他能力，风险面被大幅压缩。我见过不少项目为了偷懒，用ipcRenderer.send和ipcRenderer.on传了一堆自定义事件，最后通信全凭记忆拼字符串，排查起来极其痛苦，这就是没有约束导致的复杂度失控。

2.2 IPC通信的两个设计和两个禁忌

IPC是进程之间通信的桥梁，也是很多性能问题和逻辑bug的温床。基于实践，我总结出几条经验。

第一个设计原则是：能用invoke/handle解决的事情，不要用send/on。invoke/handle自带请求响应和异常处理，调用方可以拿到返回值，逻辑上更好理解。send/on是纯事件广播，适合做“主进程主动推送通知给渲染进程”这种场景，比如下载进度、扫描结果、后台任务状态变化。反过来使用就会很别扭：页面发一个send出去，然后在某个on里等结果，中间一旦漏监听、重监听，数据就乱套了。

第二个设计原则是：数据传输量和频率都要克制。有人习惯把所有数据都丢进IPC里，比如一次性传几万条表格数据。IPC的本质是进程间拷贝，传大块数据时会卡点，既有序列化开销，也有内存复制开销。我实际碰到过渲染进程处理完一份几MB的数据，最终本地磁盘写了一份、IPC又传了一遍，界面卡住两秒钟的案例。更好的做法是：大数据直接在主进程侧处理，渲染进程只拿处理结果；或者用文件路径作为引用，渲染进程需要内容时再分段读。如果是高频小数据，可以把多个值合并到一个对象里一次发，减少通信次数。

两个禁忌一个原则性风险，一个可维护性风险。第一个禁忌是：不要在主进程的某个事件回调里做重量级同步操作，比如同步读大文件、跑大规模循环。主进程一旦阻塞，所有窗口的绘制、系统事件响应全部跟着卡顿，表现就是页面没反应、转圈、白屏。第二个禁忌是：不要用全局变量在窗口之间互相塞数据。Electron单实例多窗口的场景太常见了，窗口A改了配置，窗口B要同步，最干净的做法是维护一个共享存储（主进程持有），再通过广播事件通知各窗口重新读取。全局变量就是无管制的状态，项目一大改起来就是拆炸弹。

3. 搭一个经得起长期维护的Electron工程骨架

很多人用Electron做项目，最初几天是兴奋的，因为跑一个窗口、写一个页面太简单了。可一旦业务复杂起来，你天天要面对的是：主进程代码和页面代码混在一起、生产环境和开发环境路径不同、打包之后静态资源404、依赖包被打进产物里。这些问题基本都能靠工程化设计提前规避，而不是靠修修补补。

3.1 目录结构与角色分隔

我经过几个项目反复调整后，现在倾向于一个非常清晰的目录结构，按进程和用途切分：

my-app/ ├── electron/ │ ├── main/ │ │ ├── index.cjs │ │ ├── windows.cjs │ │ ├── ipc/ │ │ │ ├── config.ipc.cjs │ │ │ └── export.ipc.cjs │ │ └── services/ │ │ ├── storage.cjs │ │ └── updater.cjs │ └── preload/ │ ├── index.cjs │ └── api.cjs ├── src/ │ ├── renderer/ │ │ ├── pages/ │ │ ├── components/ │ │ └── store/ ├── package.json ├── electron.builder.yml └── tsconfig.json

这个结构的关键点在于：把主进程代码从渲染进程目录里彻底分离出去。很多脚手架会把主进程入口放在根目录的main.js，页面代码放在src，短时间没问题，但主进程逻辑一复杂，就会变成一根面条，而分开目录至少让你在脑子里有一条清晰的调用链：页面 -> preload暴露的接口 -> IPC -> 主进程service。同时，preload单独放一个目录，也方便在打包时只暴露必要文件。

我习惯把“每个窗口的创建逻辑”抽到一个独立的windows.cjs模块里，而不是都堆在index.cjs入口。因为窗口不是只有主窗口一种，还可能有调起子窗口、设置窗口、关于弹窗等。每个窗口有各自的webPreferences配置和安全策略，集中管理比散落各处好排查得多。另一个好处是当你需要统一修改所有窗口的加载路径和环境判断时，只要改一个文件，不用到处找。

3.2 开发、构建、调试的工程化配置

Electron开发最烦人的环节是“改代码后怎么让它生效”。主进程和preload修改后需要重启应用，渲染进程则希望在浏览器热更新。我的处理方案是：开发阶段把主进程、preload和渲染进程分别用工具编译和监听，渲染层的热更新交给前端框架内置的那套，主进程和preload则用带重载的启动脚本。

package.json里的关键脚本大概是这样：

{ "scripts": { "dev": "electron-vite dev", "build": "electron-vite build", "package:win": "electron-vite build && electron-builder --win", "package:mac": "electron-vite build && electron-builder --mac", "package:linux": "electron-vite build && electron-builder --linux" } }

用electron-vite是我比较推荐的方案，它把主进程、preload和渲染进程的打包一起处理掉了，比手动维护三份webpack配置要省心得多。它在开发模式下会自动把preload产物编译成.mjs或.cjs（取决于你的配置），并帮你处理好开发服务器地址和本地文件加载的分流。

开发与生产加载路径的区别是新手最容易踩的坑。开发模式下，渲染进程加载的是http://localhost:5173；生产模式下，加载的是file://协议下打包后的HTML文件。如果你的代码里写死了loadURL，那打包后必然白屏。正确做法是：

// main/windows.cjs const { app, BrowserWindow } = require('electron'); const path = require('path'); function createMainWindow() { const win = new BrowserWindow({ width: 1200, height: 800, webPreferences: { preload: path.join(__dirname, '../preload/index.cjs'), nodeIntegration: false, contextIsolation: true } }); if (process.env.ELECTRON_RENDERER_URL) { win.loadURL(process.env.ELECTRON_RENDERER_URL); } else { win.loadFile(path.join(__dirname, '../../src/renderer/dist/index.html')); } return win; }

开发服务器地址通过环境变量传进去，生产环境就回落到loadFile。path.join(__dirname, ...)和直接写'./src/...'的区别需要专门说一句：__dirname是当前模块所在的真实路径，打包之后应用被解压到安装目录，模块里的相对路径仍然是从当前文件出发反推的，所以基本不会错；而用'./src/...'这种相对于工作目录的写法，在开发环境可能碰巧能跑，在生产环境只要当前工作目录变了就完蛋。

调试方面也有个经验：除了用Chrome DevTools，一定要开着main进程的Node inspector。在启动命令里加上--inspect=9222，然后在Chrome里访问chrome://inspect，就能像调试浏览器代码一样调试主进程，打点、看变量、分析堆栈。很多人写主进程代码靠console.log一遍遍打印，效率差太多了，遇到IPC调用链深的问题几乎无从下手。

4. 打包、签名、自动更新：发布链路里的硬骨头

开发完成只是开始，如何把应用发到用户手里并且能在新版本时顺利升级，才是Electron项目里最容易被低估的部分。我见过太多demo项目能在开发环境完美运行，但一打包就出现各种奇怪问题：白屏、图标不显示、签名失败、更新下载后替换失败。这里面的坑非常深，而且Windows和macOS的机制还不同。

4.1 electron-builder配置一份三端产物

打包方案上，我会推荐electron-builder，它对三大平台的支持都比较成熟，配置也更语义化。下面这份配置是从多个项目里沉淀下来的，拿来就能用：

# electron.builder.yml appId: com.example.desk-app productName: DeskApp directories: buildResources: build output: release files: - "!**/*.map" - "!**/.vite/**/*" - "dist/**/*" - "electron/**/*" asar: true win: target: - nsis icon: build/icon.ico signingHashAlgorithms: - sha256 nsis: oneClick: false allowToChangeInstallationDirectory: true createDesktopShortcut: true shortcutName: DeskApp mac: target: - dmg category: public.app-category.utilities hardenedRuntime: true gatekeeperAssess: false entitlements: build/entitlements.mac.plist entitlementsInherit: build/entitlements.mac.plist linux: target: - AppImage category: Utility

有几个地方非常值得展开。asar: true会把你的应用源码打包成一个归档文件，既保护源码又减少文件数量，但要注意：如果你在主进程里用fs去读项目目录下的某个配置文件，路径需要经过process.resourcesPath和asar解包逻辑，不能直接读。更常见的做法是把需要运行时修改的数据放到用户数据目录（app.getPath('userData')），不要把可变数据放在安装目录里，因为Windows下安装目录往往是受保护的程序文件位置，普通用户没有写权限。

Windows上做NSIS安装包时，我踩过一个很隐蔽的坑：如果产品名或安装目录路径里包含了某些特殊字符，安装后应用可能无法启动。shortcutName和安装目录名称不要带中划线或空格以外的特殊符号，命名规则越保守越好。

macOS的注意点更多。Electron应用在macOS上签名和暂定是有讲究的，如果你只是下载依赖、打包成dmg然后在本地双击，没有签名也能跑；但要分发给别人，就绕不开签名和公证（notarization）。一旦没有做公证，用户打开时会遇到“无法打开，因为Apple无法检查其是否包含恶意软件”的提示，这个体验非常劝退。我在CI里做过完整的签名和公证流程，最核心的就是把证书放在一个安全的环境变量里，并且把两个entitlements文件配好，尤其要加上com.apple.security.cs.allow-jit之类与Electron运行时相关的权限，否则打包出来的应用可能会闪退。

4.2 自动更新的升级策略与更新时机

自动更新是桌面应用差异于Web应用最大的地方，也是最能体现专业度的地方。我建议使用electron-updater配合一个静态文件服务器或者对象存储来发版。原理很简单：应用启动时向更新服务器请求最新版本信息，服务器返回版本号和下载地址，应用再决定是否下载安装。

更新时机的设计比更新本身更重要。如果应用一启动就弹“立即更新”、然后强制用户重启，用户会觉得这个软件很烦人；如果完全不提示，那你的修复永远没法到达用户。业内常见的做法是：启动时后台静默检查，发现有新版本后先下载，等用户下次关闭应用或空闲时再提示安装。electron-updater里可以通过监听update-downloaded事件，在下一次用户点退出时调用quitAndInstall()：

const { autoUpdater } = require('electron-updater'); autoUpdater.autoDownload = false; autoUpdater.on('update-available', (info) => { const result = dialog.showMessageBoxSync({ type: 'info', title: '发现新版本', message: `当前版本 ${app.getVersion()}，发现新版本 ${info.version}，是否现在下载？`, buttons: ['稍后', '立即下载'], defaultId: 0, cancelId: 0 }); if (result === 1) { autoUpdater.downloadUpdate(); } }); autoUpdater.on('update-downloaded', () => { // 在用户触发退出时调用 autoUpdater.quitAndInstall(false, true); });

这里的细节是：即使你选择“稍后”，也不要在会话中途强制打断用户。可以把已下载的更新信息保存在内存里，监听应用的关闭事件，下次用户主动退出时静默完成安装。这样用户不会觉得被打扰，版本更新率反而更高。

自动更新在某些企业内网环境中会遇到下载失败、安全代理拦截等问题，所以在更新检查这块要设计重试和退避机制，不能一失败就反复请求。我通常会在启动后的3秒、30秒、60秒各检查一次，仍失败就下一轮应用启动再看。更新逻辑越克制，线上事故越少。

5. 性能优化的真实战场：白屏、卡顿与内存泄漏排查

Electron被吐槽最多的一点就是“内存占用高、用久了变卡”。这话一半对。Electron基座确实比原生应用吃资源，但绝大多数“越用越卡、页面转圈、白屏”的问题，其实是应用自己的代码写差了，跟Chromium没有直接关系。我自己优化过很多“卡成PPT”的应用，最终发现根因基本都在通信设计、渲染层渲染量和内存释放上。

5.1 白屏和首屏加载慢是两回事

白屏和首屏慢经常被混为一谈，但原因完全不同。白屏意味着渲染进程没有成功加载出页面内容，多半是路径问题、加载配置错误、渲染进程崩溃；首屏加载慢则是页面代码太多了，或者主进程和渲染进程之间同步操作卡住了渲染，导致页面空白时间过长。

排查白屏时，我第一个看的是主进程控制台有没有报错，第二个看渲染进程的开发者工具Console里有没有脚本错误。生产模式下很多错误不会弹出来，所以我会在webContents上挂一个render-process-gone的监听，应用崩溃后主动提示用户重新加载或重启，不至于留一个死窗口让用户干瞪眼：

win.webContents.on('render-process-gone', (event, details) => { console.error('渲染进程异常退出', details.reason); dialog.showMessageBox({ type: 'error', title: '页面遇到问题', message: '页面加载出错，是否需要重新加载？', buttons: ['重新加载', '关闭窗口'] }).then((res) => { if (res.response === 0) win.reload(); }); });

首屏加载慢就复杂一些。核心思路是分阶段构建页面：先显示一个极简的加载壳（只有应用的Logo和一个进度条），同时再去执行那些耗时的初始化任务。我习惯在ready-to-show事件里再显示窗口，避免窗口创建后一片白：

const win = new BrowserWindow({ show: false }); win.once('ready-to-show', () => win.show());

另外，不要把所有第三方模块都放在入口文件里直接import。Electron渲染进程虽然是本地资源，但代码包越来越大之后解析和执行也会变慢，该做路由懒加载就做路由懒加载，该拆包就拆包。有人以为桌面应用本地跑所以不用在意打包体积，其实不对，启动加载的执行时间就是用户体验的一部分。

5.2 内存泄漏的定位方法

内存泄漏是Electron应用“越用越卡”的最大元凶。最常见的有两种路径：一是渲染进程里的事件监听器反复注册没有移除，窗口关闭后有对象仍然被全局引用；二是主进程里的定时器、IPC监听器没有清理，导致本该释放的对象一直驻留。

定位内存泄漏最快的办法是打开开发者工具的Memory面板，做三次“录快照、做操作、再录快照”，比较两份快照之间的Retained Size，看哪些对象以不符合预期的规模增长。常见嫌疑是：DOM元素、数组容器、闭包引用的对象。Electron应用里还有一个特殊嫌疑：渲染进程的BrowserWindow对象被主进程的全局数组引用住了，窗口已经关闭但对象一直不被GC，日积月累主进程内存一路涨。

还有一个很多人不知道的坑：隐藏窗口并不等于释放资源。如果你的应用关了主窗口但保留了托盘，托盘窗口的渲染进程实际上可能还在后台跑定时器、WebSocket、动画。这些任务会持续消耗CPU和内存，而且用户根本看不见。针对这种场景，我通常会设计一个“托盘待机模式”：窗口隐藏后，向所有渲染进程广播一个app:suspend事件，页面收到后停掉定时器和动画；窗口重新显示时再恢复。如果不这么做，用户会把关机前一直开着托盘应用的耗电和卡顿都归结为“Electron好垃圾”，虽然真正的原因是你的后台任务没停。

另外，不要过早用app.commandLine.appendSwitch('js-flags', '--max-old-space-size=4096')这种手段去调大V8堆内存。如果你发现某个渲染进程内存已经超过1GB，先回去审视代码，而不是给V8加配额——配额调大以后只会让内存泄漏的症状延后，该崩的时候一样崩，而且会更难排查。

6. 从多次踩坑里沉淀的Electron检查清单

文章写到这里，我准备把若干次实战中遇到的高频问题和对应的防御性做法，整理成一份可以直接对照检查的清单。这些都不是教科书里的标准条目，而是真实项目里反复出现过、靠堆经验才填平的坑。

6.1 高频问题与快速诊断

这些现象里，单实例锁的问题我想多提一句。桌面应用默认允许启动多个实例，但很多业务场景下这会造成数据竞争，比如两个实例同时修改同一个配置文件。Electron提供了标准的单例锁API：

const gotTheLock = app.requestSingleInstanceLock(); if (!gotTheLock) { app.quit(); } else { app.on('second-instance', (event, commandLine, workingDirectory) => { // 已有实例收到第二次启动的请求，可以让已有实例的主窗口恢复显示 if (mainWindow) { if (mainWindow.isMinimized()) mainWindow.restore(); mainWindow.focus(); } }); app.whenReady().then(() => { // 正常初始化 }); }

这段代码解决了“用户再次点图标打开应用，结果打开了两个程序”的尴尬问题。很多人刚做Electron时不会注意这个细节，等到用户报“我怎么开了三个标签页”时才会意识到，但那时候已经有状态错乱的风险了。

6.2 适合直接抄的防御性代码片段

除了单实例锁，我还会在每个项目里放一个统一处理窗口关闭的逻辑：分类对待“关闭窗口”和“退出应用”。比如：主窗口的右上角关闭按钮，一般只表示隐藏到托盘，而不是退出应用；只有在用户显式选择“退出”时，才真正调用app.quit()。如果处理不好这个事件分类，用户很容易出现“点了关闭以为程序退出了，但后台还在跑”的困惑，尤其是托盘应用。

let isQuitting = false; app.on('before-quit', () => { isQuitting = true; }); mainWindow.on('close', (event) => { if (!isQuitting) { event.preventDefault(); mainWindow.hide(); } }); // 托盘的退出菜单里调用 tray.on('click', () => { mainWindow.show(); }); // 托盘右键菜单中的退出项 trayContextMenu.append(new MenuItem({ label: '退出', click: () => { isQuitting = true; app.quit(); } }));

这个模式看似简单，但能挡住大部分“窗口隐现混乱”的bug。托盘逻辑里还有一个容易被忽略的地方：不要每次点击托盘都重新创建BrowserWindow。正确的做法是在应用启动时就创建好主窗口，之后只是show()和hide()，反复创建和销毁窗口既浪费资源，也可能导致状态丢失。如果你的业务确实需要每次重新加载，那也一定要做好旧窗口的引用清理，避免内存堆积。

进程退出路径上还有一个小技巧：在主进程里给uncaughtException和unhandledRejection配置兜底日志。桌面应用不像网页能轻易看控制台，用户报问题又往往描述不清，此时一份持久化的日志文件就是救命稻草。我会用主进程里最简单的fs.appendFileSync把关键错误堆栈写到app.getPath('userData')/logs/main.log，文件里带上时间戳。这样出了问题，我可以让用户把这个日志发过来，按时间线排查，效率比反复复现要高得多。

关于Electron的周边生态，我再补充一点看法：如果你要做的是一个非常偏“系统级”的应用，比如全局快捷键、开机自启、注册系统通知，electron-*生态里基本都有轮子可换；但如果要做很底层的事情，比如拦截全局鼠标事件、修改触控板手势，Electron的原生能力会变得很勉强，这时候我建议在架构设计阶段就考虑用C++扩展或一个辅助原生进程来补足，而不是把所有压力都砸给Electron运行时。

我自己实际用下来，Electron最舒服的地方在于：它是“一套代码，三端运行”里综合成本最低的。性能优化这件事，只要你不故意写烂代码，其实完全够用——多花一点心思在进程边界、通信粒度和资源释放上，Electron应用是可以做到非常流畅的。我希望这篇文章能减少你在Electron路上的试错时间，特别是那些“文档里没有明说、但项目里一定会碰到”的角落。如果看完之后，你至少对进程模型、打包更新、性能排查这几块有了更清晰的把握，那这篇分享就没白写。