Electron 的主进程和渲染进程都运行在 Node.js 环境里，这意味着你不仅可以使用 npm 上的纯 JavaScript 包，还能加载用 C++ 编写的原生模块（通常以 .node 结尾的动态链接库）。当应用遇到计算密集型任务或需要调用 JavaScript 无法直接触及的系统能力时，C++ 插件就成为了最后的“杀手锏”。
26.1.1 为什么需要原生扩展
坦白说，绝大多数 Electron 应用的性能瓶颈不在 CPU，而在 IO 或渲染。但总有一天你会碰到这类场景：
- 需要调用某个只有 C++ 接口的硬件 SDK（例如刷卡器、高拍仪、工业相机）。
- 必须处理大规模数据（例如实时压缩 4K 视频帧、加密算法极速实现）。
- 与已有的 C++ 遗留系统对接，不想用子进程的方式反复序列化数据。
这些情况下，直接编写一个 Node.js 原生扩展能够让 Electron 的主进程以接近原生的效率完成工作，同时保持代码的统一性。
26.1.2 原生扩展的开发与集成流程
创建 Node.js 原生扩展最常见的工具有两种：node-gyp 和 cmake-js，它们都能将 C++ 代码编译成 .node 文件。一个最简单的工作流是这样的：
步骤 1：搭建 C++ 扩展项目
在你的 Electron 项目根目录下创建一个子目录（如 native/），并在其中初始化一个标准的 Node.js 插件结构：
native/
├── binding.gyp # 编译配置
├── addon.cc # C++ 源码
└── package.json # 可选的元数据binding.gyp 是一个 JSON 风格的文件，告诉 node-gyp 如何编译：
{
"targets": [
{
"target_name": "myaddon",
"sources": ["addon.cc"],
"include_dirs": ["<!@(node -p \"require('node-addon-api').include\")"],
"dependencies": ["<!(node -p \"require('node-addon-api').gyp\")"],
"defines": ["NAPI_DISABLE_CPP_EXCEPTIONS"]
}
]
}C++ 源文件可以用传统的 N-API 或更现代的 node-addon-api 封装，这里以 node-addon-api 为例写一个简单的函数，返回两个数字的和：
#include <napi.h>
Napi::Value Add(const Napi::CallbackInfo& info) {
Napi::Env env = info.Env();
if (info.Length() < 2 || !info[0].IsNumber() || !info[1].IsNumber()) {
Napi::TypeError::New(env, "Expected two numbers").ThrowAsJavaScriptException();
return env.Undefined();
}
double a = info[0].As<Napi::Number>().DoubleValue();
double b = info[1].As<Napi::Number>().DoubleValue();
return Napi::Number::New(env, a + b);
}
Napi::Object Init(Napi::Env env, Napi::Object exports) {
exports.Set("add", Napi::Function::New(env, Add));
return exports;
}
NODE_API_MODULE(myaddon, Init)然后在该目录下安装依赖并编译：
cd native
npm install node-addon-api
npx node-gyp rebuild编译成功后，build/Release/myaddon.node 就会出现。
步骤 2：在 Electron 主进程中使用
将编译好的 .node 文件复制到一个 Electron 可访问的位置，或者直接在打包配置里包含它。然后就像 require 一个普通模块一样使用：
// main.js
const path = require('path');
const nativeAddon = require(path.join(__dirname, 'native/build/Release/myaddon.node'));
console.log(nativeAddon.add(3, 5)); // 输出 826.1.3 关键难点与避坑指南
将原生扩展引入 Electron 并非一帆风顺，实际工作中常见的问题和应对策略如下：
重新编译（Rebuild）
你开发的 C++ 插件是针对你系统上的 Node.js 头文件编译的，但 Electron 内置的 Node.js 版本可能与开发机上的系统 Node.js 不相同，而且 V8 引擎的 ABI 也不同。因此，在 Electron 中加载时通常需要针对 Electron 的 headers 重新编译。
推荐使用 electron-rebuild 这个工具，它能自动检测所有依赖中的原生模块，并为当前 Electron 版本重新编译：
npm install --save-dev @electron/rebuild
npx electron-rebuild -w myaddon -v <electron-version>把这条命令放到 postinstall 脚本里，就能保证每次 npm install 后原生模块都适配当前的 Electron。
N-API 版本一致性
尽量使用稳定的 N-API（通过 node-addon-api），这样你的插件可以在不同的 Node.js 版本间二进制兼容，减少重新编译的需要。避免直接使用 V8 或 nan，它们与 Electron 更新捆绑更紧密。
平台兼容性
C++ 代码在不同操作系统上编译可能需要不同的工具链（Windows 需要 Visual Studio Build Tools、macOS 需要 Xcode Command Line Tools、Linux 需要 g++ 与 libx11-dev 等）。在 CI 环境中要确保所有平台的编译都能通过。
安全与进程隔离
原生扩展拥有与主进程同等的系统权限。绝对不要从渲染进程直接加载原生模块（即使用 nodeIntegration 或 contextIsolation: false），这会把整个系统的控制权暴露给网页内容。正确做法是：在主进程中加载原生扩展，并通过 IPC 暴露有限、安全的接口给渲染进程。
26.1.4 真实场景：加解密加速
假设你正在开发一个端到端加密的聊天应用，需要频繁地进行 AES-GCM 加密操作。纯 JavaScript 实现在处理大文件时可能会带来明显的主线程阻塞。你可以将加解密部分用 C++（借助 OpenSSL 库）实现为原生扩展，然后在主进程中调用，再通过 IPC 通知渲染进程进度。这样既保证了加密速度，又不影响界面响应。
最终，用户的体验与使用纯 JS 无异，但性能提升巨大，而且你的核心加解密逻辑保留在原生代码层，更难以被逆向或篡改。
引入 Node.js 原生扩展是 Electron 能力边界的最远延伸。它不是常规武器，但在关键战斗中可以弥补纯 Web 技术的短板。掌握这一节的内容，能够让你在需要时毫不犹豫地挥出这把 C++ 的“手术刀”，而不被“Electron 只能写前端”的刻板印象所限制。