Electron 性能差？那是你没把重活拆进 utilityProcess

「Electron 应用卡、占内存、启动慢」——这话一半是真的，一半是写法背的锅。Electron 主进程本质上是一个单线程的 Node.js：你在里面跑 CPU 密集的计算、做大量文件遍历、加载原生模块、spawn 子进程，事件循环被占住，界面就掉帧、点不动、白屏假死。

解法不是换框架，而是把重活从主进程挪出去。Electron 20+ 提供了官方的 utilityProcess.fork()，专门用来起一个独立、受生命周期管理的 Node.js 子进程。主进程只做调度和界面桥接，重活全部外派。

主进程为什么会卡

很多人把渲染进程和主进程搞混：界面卡，锅在主进程。因为：

窗口的创建、IPC 的分发、原生菜单的响应、BrowserWindow 的生命周期，全在主进程的单线程事件循环里；
你一旦在主进程写 for 大循环、同步读大文件、密集正则、阻塞式网络请求，事件循环就被占满，所有窗口一起卡；
原生模块（比如上篇讲到的 koffi 调 Win32）一旦段错误，崩的是主进程，整个应用直接没。

所以经验法则：任何超过几毫秒、可能阻塞、可能崩的事，都不该放在主进程。

utilityProcess 是什么，和另两个有啥不同

Node 生态里能跑「后台代码」的有三种，容易混：

方案	隔离级别	能加载原生模块吗	适合什么
`worker_threads`	同进程内多线程	不行（共享主进程加载器，原生模块受限制）	纯计算、不碰原生模块
`child_process.fork`	独立进程	可以	通用，但要自己管生命周期
`utilityProcess.fork`	独立进程（Electron 托管）	可以	桌面应用的常驻引擎、原生模块、隔离风险代码

utilityProcess 比裸 child_process.fork 好在哪：它走 Electron 自己的进程托管，能给定 serviceName、能配 env/cwd/execArgv、崩溃不影响主进程，而且从 electron 模块直接拿，生命周期和应用绑在一起，关应用自动回收。对桌面应用来说，这是最省心的「正经子进程」。

我的真实架构：3 个 utilityProcess 子进程

我的桌面应用现在常驻着 3 个 utilityProcess 子进程，各自扛一类重活：

// 主进程里，把三类重活分别外派
const { utilityProcess } = require('electron');

function spawnEngine(name, file) {
  return utilityProcess.fork(__dirname + '/' + file, [], {
    serviceName: name,
    env: { ...process.env, NODE_ENV: 'production' },
    stdio: 'pipe',
    cwd: __dirname,
  });
}

const collector = spawnEngine('collector-engine',  'collector-engine.js');
const flowlab  = spawnEngine('flowlab-engine',    'flowlab-engine.js');
const mycomp   = spawnEngine('mycomputer-engine', 'mycomputer-engine.js');

collector-engine：数据采集引擎。内部用 worker pool 跑并发扫描，并做垃圾内容过滤——这种 CPU 密集 + 长任务，放主进程界面必卡。
flowlab-engine：flowlab 执行引擎。它要在沙箱里双执行且支持重入——同一份逻辑可能被反复调用、中断、再进入，放在独立进程里用状态机管最干净，也避免污染主进程堆。
mycomputer-engine：系统信息类，所有 Win32 调用都收在这里（就是上篇那层 koffi 懒加载）。段错误崩的只是它，主进程和界面照常。

三个进程里，只有 mycomputer-engine 加载系统 DLL，其余两个根本不碰——内存和权限边界都很清楚。

进程间怎么通信

子进程里通过 parentPort 收发消息（它是 Electron 给 utilityProcess 准备的，等价于 process 层面的消息通道）：

// collector-engine.js —— 运行在 utilityProcess 里
const { parentPort } = require('electron');

parentPort.on('message', (msg) => {
  if (msg.type === 'scan') {
    const result = doHeavyScan(msg.path); // 重活，不阻塞主进程
    parentPort.postMessage({ type: 'result', result });
  }
});

主进程侧用 child.postMessage 发、child.on('message', ...) 收。如果是需要双向高频通信（比如引擎往界面流式吐结果），用 MessageChannelMain 建一个 MessagePort 传过去，比反复走 postMessage 更顺：

const { utilityProcess, MessageChannelMain } = require('electron');
const child = utilityProcess.fork(__dirname + '/flowlab-engine.js', []);
const { port1, port2 } = new MessageChannelMain();
child.postMessage({ type: 'init', port: port2 }, [port2]); // port2 转移给子进程
port1.on('message', (m) => renderToUI(m));

注意结构化克隆：postMessage 走的是深拷贝。传小对象没问题，传几十 MB 的数组会很贵——这种大块数据要么走文件 / 临时存储，要么用 MessagePort 配合 Transferable 转移所有权而不是拷贝。

踩过的坑

重入。flowlab 引擎要「双执行且可重入」：同一个引擎实例可能被两份输入交替驱动。第一版我把它写成单例状态机，结果第二次进入把第一次的状态冲掉了。改成每次执行开独立的上下文对象，引擎本身只做调度，才稳住。
序列化成本。早期我把整棵扫描结果树直接 postMessage 回主进程，几万条记录一拷贝，界面反而被 IPC 卡住。后来改成分批 + 增量，每批几百条，界面实时刷新还不卡。
别无脑起进程。utilityProcess 不是免费的：每个都占一份 Node 运行时内存。我见过有人给每个请求起一个子进程，内存直接爆。正确做法是常驻 + 内部 worker pool，像 collector-engine 那样一个进程扛所有扫描任务。
启动参数。子进程要跑实验性特性或指定架构时，靠 execArgv 传，别指望继承主进程的 flag——默认是不继承的。

一句话心法：主进程只做调度，重活全部外派。这是让 Electron 桌面应用不卡、不崩的核心。

什么时候该用，什么时候别用

该用 utilityProcess 的：CPU 密集计算、文件 / 磁盘批量遍历、加载原生模块（如 koffi 调系统 API）、跑不可信 / 易崩的代码、需要常驻的后台引擎。

不该用的：仅仅是想「异步一下」——那种用 setImmediate 或 worker_threads 就够了，不值得为一个小任务起一个完整 Node 进程；以及频繁创建销毁的短任务——开销会吃掉收益。

判断标准很简单：这件事会不会阻塞事件循环、会不会崩、要不要加载原生模块？三个里占一个，就丢进 utilityProcess。

「Electron 性能差」往往不是框架的错，是重活全堆在主进程里。把引擎拆成独立子进程，界面立刻就活了。系统调用放哪一层、重活怎么隔离，这两篇连起来，就是我这套桌面应用的骨架。

从架构到打包的实战，B站 / 抖音搜 codevtool 都能看到。