Electron 应用一旦出现界面点不动、窗口拖不动、菜单弹不出来，大多数情况不是渲染进程的问题，而是主进程里堆了同步重活。主进程同时承担窗口事件、IPC、原生菜单、系统集成这些事，只要有一个任务长时间占住事件循环，整个应用的 UI 消息就排不上队，表现出来就是“无响应”。适合先问自己的场景是：界面卡住时，CPU 占用是否长期停在某个核上？关闭窗口再重开是否恢复？如果重开就好了，那基本可以确认是主进程阻塞，而不是系统资源耗尽。

先确认阻塞源

判断主进程是否阻塞，最快的方法是观察界面交互是否出现数十秒以上的卡顿，同时打开系统任务管理器查看 Electron 主进程的 CPU 占用。如果 CPU 接近满核且不下降，十有八九是有同步任务卡在主进程的事件循环里。可以用一个 setInterval 每秒打印次日志，假若打印中断好几秒又重新出现，那段中断的耗时通常就是主进程里的同步重活。这招在开发环境很好用，生产环境可以临时给循环内的关键分支加打点，但记得上线前移除。

如果日志中断时间不稳定，有时几百毫秒，有时几秒，就需要进一步定位是哪个函数的耗时。可以在可疑函数入口和出口各记一次时间戳，把差值超过阈值的分支打上 warning。注意别在打点里做字符串拼接这类额外操作，否则测量出来的是打点自身的开销。

把任务移出主进程

异步化的第一选择是把耗时任务送出主进程。Electron 提供了 utilityProcess，可以在主进程里 fork 一个 Node.js 子进程，处理文件批量压缩、数据解析这类重活。用法上和 child_process 类似，但 API 更贴近 Electron 的消息模型。主进程收到渲染进程的请求后，先为这个任务创建一个子进程，任务完成后把结果通过 message 事件回传。整个过程主进程只负责收发消息，事件循环不会被卡住，UI 自然就响应了。

在选择 utilityProcess 之前，先确认任务是否真的适合独立进程。如果任务需要频繁和主进程交换中间状态，那每次通信都有序列化和 IPC 开销，反而不如用 worker_threads。适合 utilityProcess 的典型场景是：一次调用处理一整批文件、解析较大的 JSON 或数据库文件、压缩目录。这类任务输入输出清晰，中间不需要和 UI 交互。

实现时注意子进程的退出码。任务完成后要让子进程主动退出，避免遗留孤儿进程。如果任务抛出异常，需要在主进程侧监听 error 和 exit 事件，把错误信息回传给调用方，而不是让渲染进程一直等待。

先检查同步 IPC

异步化最容易踩的坑是同步 IPC。ipcRenderer.sendSync 会阻塞渲染进程直到主进程返回，如果主进程恰好也在忙，整个应用会彻底无响应。改造的时候，把 sendSync 全部换成 ipcRenderer.invoke，主进程用 ipcMain.handle 来响应。并且可以给 handler 包一层超时控制，避免某个操作一直不返回把渲染进程吊死。渲染进程端记得用 async/await 或 Promise，别在事件处理函数里写死循环。

搜索一下代码里是否还有 sendSync 残留。Windows 上如果看到渲染进程的 CPU 不高但界面卡住，多半是渲染进程在等主进程的同步返回。ipcRenderer.invoke 本身不保证任务一定快，它只是把同步阻塞变成了异步等待，真正耗时还是要在主进程里判断。如果主进程的 handler 里仍然在做复杂的计算，invoke 只是让渲染进程不死，UI 依然会卡。所以完成 IPC 改造后，回头再看主进程 handler 里有没有同步重活。

控制子进程并发

把任务移到子进程后，还需要控制并发数量。如果渲染进程连续发起多个大任务，每个任务都新开一个 utilityProcess，系统资源可能在几秒内被耗尽。建议在主进程里维护一个简单任务队列，限制同时运行的子进程数量。比如同时最多跑 2-3 个重任务，其余排队。这个数量不是固定标准，需要结合用户机器核心数、任务的内存占用和你的业务超时要求来调。核心数检测可以用 os.cpus().length，但不要直接拿它当并发上限，还得留出主进程和渲染进程的余量。

子进程超时也是必须设置的。utilityProcess 没有内置的超时参数，需要自己用 setTimeout 包裹，到点就 child.kill()。超时后不要只杀进程，还要把这次任务标记为失败并通知渲染进程，否则界面会一直显示加载中。如果任务支持断点续跑，可以在子进程里定期往主进程发送进度和临时结果，主进程在超时后可以把这个状态存下来，供下次重试使用。

验证主进程是否松绑

改造完成后，最直接的验证方式是反复触发之前卡顿的操作，同时观察窗口拖拽和菜单响应。如果界面能保持交互，说明主进程的阻塞窗口已经消失。更准确一点，可以用 Electron 自带性能监控记录主进程的 Task Duration 和 Event Loop 延迟，和改造前做对比。这里不需要特定工具，应用里临时加一个性能统计页面就能收集数据。重点观察事件循环延迟是否还有超过 200ms 的尖峰，如果有，说明主进程里仍然存在某个同步任务没清理干净。

另外还要观察子进程的内存变化。跑几轮压力测试，如果子进程退出后内存没有完全释放，可能存在句柄泄漏或事件监听未移除。把压力测试脚本固定到 CI 里，虽然不能自动判断 UI 响应，但至少可以在每次改动后检查事件循环延迟是否回归。如果后续有人把一段同步重活直接塞进主进程，CI 检测会给出红点，这比事后线上事故要容易处理。

异步化不是把所有任务都搬到子进程就结束。关键是要找到一个边界：哪些任务必须留在主进程（比如窗口事件、IPC 注册、系统原生操作），哪些可以交给子进程，哪些可以改成队列慢慢跑。这个边界需要结合你的业务场景来判断，不能套用固定模板。只要每次改动都能用日志和延迟数据验证，后续维护时就不会再靠猜了。