IPC（进程间通信）是 Electron 应用中最核心的通信机制。主进程与渲染进程之间、以及不同窗口的渲染进程之间，都需要通过 IPC 传递消息。在日常开发中，IPC 用起来很简单：一个 invoke 调用，一个 handle 回应。但当数据量变大、结构变复杂、或者涉及跨线程的 Node.js 原生模块时，一些隐蔽的问题就会浮现。这一节会聚焦三个高频痛点：数据序列化、大文件传输，以及与跨线程相关的坑。
28.4.1 数据序列化的隐性代价
Electron 的 IPC 底层依赖 Chromium 的结构化克隆（Structured Clone）算法。这意味着你通过 ipcRenderer.invoke 或 ipcMain.handle 传递的参数和返回值，都会经历一次深拷贝式的序列化与反序列化。
大部分时候这没什么问题，但在两种情况下需要特别警惕：
1. 传递不可克隆的对象
结构化克隆不支持函数、Symbol、WeakMap、Error 对象以及包含循环引用的对象。如果你试图传递一个包含方法的 Vue 组件实例，或者一个带有 toJSON 自定义序列化的复杂对象，IPC 会直接抛出异常。实际开发中的常见翻车场景是：渲染进程想把一个含有 Date 实例的复杂对象传给主进程，结果收到的却是一个 ISO 字符串或者时间戳 —— 因为结构化克隆会把 Date 转化成字符串。
正确的处理方式是手动“扁平化”数据，只传递纯 JSON 可序列化的对象。如果必须携带无法序列化的类型，可以拆分成多个参数，或者改用共享内存（如 SharedArrayBuffer）的方式传递原始数据，再通过 IPC 传递内存地址的引用。
2. 序列化本身的性能开销
当传递的数据量很大（例如一个包含 1 万条记录的数组），结构化克隆的 CPU 和内存消耗不容忽视。实测中，传输一个 10MB 的 JSON 对象可能带来上百毫秒的阻塞，足以让界面出现明显卡顿。解决方案包括：
- 分片传输：把大数组拆成小块，分批通过 IPC 递送。
- 尽量只传“必要数据”：比如只传主键，让接收方自己处理后续逻辑。
- 对于超大数据集，考虑改用文件系统或共享内存作为中介。
28.4.2 大文件传输的正确姿势
electron 应用常常需要处理文件上传、本地文件导出或者媒体数据的跨进程传递。很多开发者下意识地使用 IPC 的 invoke 传递整个文件的 Buffer，这在文件很小时（几 KB）没什么问题，但当文件超过几十 MB 时，问题就来了：IPC 会把整个 Buffer 序列化并复制到接收进程的内存中，导致内存翻倍、卡顿甚至进程崩溃。
实用方案一：用流代替整块数据
向渲染进程交付一个本地文件时，不要在 IPC 中返回整个文件的 Buffer，而是通过 HTTP 本地服务器或自定义协议（protocol）来提供可流式读取的 URL。例如，主进程启动一个 http.createServer 监听一个随机端口，然后把文件的 URL 通过 IPC 发给渲染进程，由渲染进程的原生 fetch 或 StreamSaver 逐块下载。这样做的好处是数据不会一次性撑满内存，而且可以利用浏览器的缓存策略。
实用方案二：直接共享文件路径
最简洁的方式是只传输文件的本地路径。渲染进程拿到路径后，可以通过 fs（前提是开启了适当的权限）直接读取，或者使用 file:// 协议加载图片、视频等。对于跨操作系统的路径，确保使用 path 模块规范化。同样，如果数据需要从渲染进程传到主进程保存，也可以先让渲染进程把数据用 fs.writeFile 写入临时文件（通过 broker 权限），再把路径发给主进程处理。
实用方案三：使用 MessagePort
对于需要双向低延迟大数据量的场景（例如实时音视频流），可以利用 ipcRenderer.postMessage 配合 MessagePort。它允许创建一对相互连接的端口，可以传递 ArrayBuffer、Buffer 等可转移对象（Transferable），避免内存复制。这种方式适用于固定通道的持续数据流。
28.4.3 跨线程问题的现实案例
Node.js 本身是单线程模型，但很多原生模块（比如 sharp 图片处理、sqlite3 编译、worker_threads）会在内部创建额外线程。这些线程中产生的数据结构，如果直接通过 IPC 传递，往往会因为跨上下文而失效。
典型问题一：来自 Worker 线程的数据
假设你在主进程中使用了 Node.js 的 worker_threads 来处理图像压缩。Worker 线程在结束后通过 postMessage 返回一个 Buffer 给主线程的 handler，主线程再把这个 Buffer 通过 Electron IPC 发给渲染进程。这个流程在理论上是可行的，但需要注意 Worker 的 postMessage 使用的是结构化克隆，并且支持可转移对象。如果 Worker 返回的 Buffer 包含一个 .buffer 属性（如 TypedArray），需要确保在传递给 Electron IPC 前它是完整的、未被分离（detached）的。更稳妥的方法是让 Worker 直接将结果写入共享内存或文件，然后主进程把路径发出去。
典型问题二：不安全的跨上下文引用
有些原生模块会缓存 JavaScript 对象，比如通过 v8::Object 持有回调引用。如果您尝试把这些“包装”后的对象通过 IPC 发送，结构化克隆会尝试序列化这个对象，结果往往是抛出一个无法克隆的异常（“an object that could not be cloned”）。遇到这种情况，处理方法是明确从这些对象中提取出纯数据，在 IPC 之前手动将其转化为普通对象。
典型问题三：竞态与死锁
在多窗口应用中，一个窗口的渲染进程可能会调用 IPC 请求主进程执行耗时操作，而主进程又在同一个线程中处理另一个窗口的同步请求。Electron 的主进程本身是单线程的（Node.js 事件循环）。如果某个 handle 里执行了长时间同步代码，整个主进程会阻塞，影响所有窗口和系统事件。这就是所谓的“跨线程等待引发的卡死”。
应对原则：
- 主进程 handle 内部避免任何同步的 CPU 密集型操作，例如
execSync、大循环加密等。 - 对于需要较长时间的操作，使用
Promise包装异步逻辑（例如将计算丢给worker_threads，然后 Promise resolve），让主进程的事件循环可以继续处理其他 IPC。 - 限制渲染进程向主进程发出的并发请求数，避免主进程过载。
总结来说，IPC 虽然封装得很好，但开发团队必须对序列化开销、内存策略和线程安全保持足够的敏感。一个成熟的 Electron 应用总会在这几个方面做出周全的设计，以确保即便在数据密集或者多线程环境下，通信依然快速、可靠，且不会引发难以排查的崩溃。