Electron 应用的内存泄漏通常比纯 Web 页面更难察觉，因为它往往需要长时间运行（用户可能整天不关窗口），而且每个渲染进程都有独立的堆，一旦发生泄漏，不仅占用内存变大，还可能拖慢整个系统的响应。好在多数泄漏的源头是有规律可循的，掌握几个高频场景和排查手段，就能把风险控制在可接受范围内。
20.2.1 常见泄漏场景
1. 渲染进程内未清理的事件监听器
最典型的例子是你在某个组件 mounted 时注册了 IPC 监听，但 beforeUnmount 时忘了 removeListener。每次打开窗口或切换页面，监听器都会多一份，而它们引用的闭包又持有大量 DOM 和组件状态，导致整个旧视图无法被垃圾回收。
// ❌ 错误：监听器越积越多
useEffect(() => {
window.api.on('data-update', handleData);
}, []);
// ✅ 正确：组件卸载时移除
useEffect(() => {
window.api.on('data-update', handleData);
return () => window.api.removeListener('data-update', handleData);
}, []);同样的道理也适用于由主进程发来的其他事件（如窗口状态变化、系统主题切换），以及对 DOM 元素直接捆绑的 addEventListener。
2. 大体积数据在 IPC 中被序列化传递
主进程和渲染进程之间的 IPC 通信会复制数据（即便使用 SharedArrayBuffer 也要小心处理）。如果你在短时间内频繁地通过 ipcRenderer.invoke 或 send 传输大量 JSON 数据（比如整张图片的 base64、批量文件内容），这些临时副本会被 V8 引擎分配内存，并且在不再使用后需要等待垃圾回收。如果这种调用过于密集，内存会先涨后降，但峰值容易造成卡顿。更可怕的是，如果某处代码不小心保留了这些数据的引用，就演变成了真实泄漏。
建议做法：
- 大文件尽量在主进程直接处理，只向渲染进程传递路径或缩略信息。
- 使用流式传输（比如通过 HTTP 本地服务器或 WebSocket）替代一次性 IPC 大包。
- 对于可以被垃圾回收的临时数据，在不用时显式置空引用。
3. 未销毁的定时器和异步任务
setInterval、setTimeout，以及未 cancel 的异步请求（如 fetch、axios 等），如果组件被销毁时没有被清除，回调里还引用着组件状态，就会造成闭包泄漏。
// ❌ 区间定时器在窗口关闭后仍在运行
const timer = setInterval(() => {
fetchData(); // fetchData 仍持有旧作用域的变量
}, 5000);
// ✅ 窗口关闭时销毁
window.addEventListener('beforeunload', () => {
clearInterval(timer);
});特别需要注意的是，Electron 的渲染进程不会被浏览器那样“自动杀死”，用户可以通过关闭窗口来退出进程，但如果你有多窗口应用，某个隐藏窗口可能一直在后台运行，它的定时器会持续消耗内存。
4. 重复创建 BrowserWindow 或 BrowserView 未正确回收
当你在主进程中频繁创建新窗口，但在窗口关闭后没有及时将引用置 null，又或者监听器、子进程等未被释放，主进程的内存也会持续上涨。
// ❌ 窗口关闭后仍被 `win` 变量引用
app.on('ready', () => {
let win = new BrowserWindow({...});
win.on('closed', () => {
// 仅仅不做任何事，win 仍然持有这处闭包引用
// 导致完整的 BrowserWindow 实例无法被 GC
});
});
// ✅ 消除引用
win.on('closed', () => {
win = null;
});BrowserView 同理，使用 <webview> 标签时也要确保及时移除。
5. 系统托盘、Menu 或 Notification 的循环引用
这些对象通常在主进程中创建，且生命周期较长。如果它们的回调函数引用了更大的对象（比如某个窗口实例），而这些对象本该被释放，就会导致：
Tray -> callback -> BrowserWindow（已经关闭但无法 GC）解决方案同样是：在窗口关闭时清掉相关回调，或者在托盘本身销毁时移除监听器。
6. 未释放的 Node.js 流、文件句柄或子进程
使用 fs.createReadStream 后忘记关闭，或者 child_process.spawn 后未清理。这些虽然不是 JavaScript 堆内存，但会占用操作系统的资源（文件描述符、进程句柄），影响应用稳定性。时间长了可能触发 EMFILE 错误或者导致主进程响应缓慢。
20.2.2 排查方法与工具
排查 Electron 的内存泄漏，不能只靠“感觉变卡”，需要结合多个维度来定位。
1. Chrome DevTools 的 Memory 面板
这是排查渲染进程泄漏的第一站。在开发模式下，打开 Electron 窗口的 DevTools（Ctrl+Shift+I），进入 Memory 面板。
- Heap Snapshot：在怀疑泄漏的操作前后，分别拍一次快照，然后使用 “Comparison” 视图查看两次快照之间新增了哪些对象。如果某种对象（比如闭包、事件监听器、DOM 节点）的数量一直增长，基本可以定位到泄漏源。
- Allocation instrumentation on timeline：录制一段时间内的内存分配情况，查看哪些函数在持续分配内存而没有被释放。可以根据栈追踪直接跳转到源码行。
2. Performance 面板的 Memory 勾选
Performance 录制时勾选 “Memory” 选项，可以看到 JS 堆、节点数、监听器数量随时间变化的曲线。如果曲线只升不降或呈阶梯状，说明存在泄漏。配合用户操作，很容易复现出“点击某按钮一次，内存就涨 10MB”的场景。
3. process.memoryUsage() 与操作系统监控
你可以在代码中定时打印 Node.js 的内存使用情况：
setInterval(() => {
const mem = process.memoryUsage();
console.log(`RSS: ${Math.round(mem.rss / 1024 / 1024)} MB, HeapUsed: ${Math.round(mem.heapUsed / 1024 / 1024)} MB`);
}, 5000);rss是进程实际占用的物理内存，包含了 V8 堆、原生内存和资源映射。heapUsed是 V8 管理的 JavaScript 堆内存。
如果 heapUsed 缓慢上涨但偶尔 GC 后会回落，那只是正常波动。但如果 rss 一直增长且永远不会下降，即便 heapUsed 被回收了，也很可能是 Native 内存泄漏（如图片 Buffer、Native 窗口句柄未释放）。这种情况下需要用到系统工具（如 Windows 任务管理器、macOS 活动监视器，或 process.memoryUsage() 的外部监控）来确认。
4. 使用 --inspect 和 Chrome DevTools 连接主进程
主进程的泄漏排查稍麻烦一点，因为它没有自带的 DevTools 窗口。可以通过命令行参数让主进程进入调试模式：
electron --inspect=9222 your-app然后在 Chrome 浏览器中访问 chrome://inspect，找到对应的 Targets 并点击 “inspect”。这样就能对主进程使用 Memory 和 Performance 面板，方法同渲染进程一样。
5. 检查事件监听器、process 和 require 缓存
一些泄漏是由于无意中保留了全局引用：
- V8 的堆快照里可以搜索
EventEmitter实例，查看哪些对象持有过多的监听器。 - Node 的
require.cache如果没有清理，会一直保留所有已加载模块的导出对象，虽然通常影响不大，但在动态加载大量模块且不断增加的场景下也会成为问题。
6. 针对生产环境的远程监控
如果问题只在用户环境出现，可以考虑在应用内埋入一个简单的状态汇报：定时采集 process.memoryUsage() 和窗口数量上报服务器，并在超过阈值时提示用户重启或自动执行轻量级回收操作。这种做法虽然不能直接修复泄漏，但可以避免严重影响用户体验，并为你提供判断问题规模的数据。
20.2.3 预防策略
- 遵循“谁创建谁清理”：任何 IPC 监听器、DOM 事件、定时器，都在创建它的组件或窗口中负责移除。
- 使用弱引用：对于缓存或观察者模式，尽量使用
WeakMap、WeakRef来避免人为延长对象生命周期。 - 控制窗口数量：多窗口应用应有窗口管理机制，及时销毁不再使用的窗口，并清空引用。
- 定期做内存基线测试：在新功能发布前，模拟长时间运行场景（例如持续操作 2 小时），记录内存曲线，若持续上涨则视为 Bug 处理。
最终，内存泄漏的排查就像剥洋葱，从外层表现（哪个进程涨内存）到内层根源（哪段代码阻止了 GC），需要一层层剥离。只要掌握上述场景和工具，绝大多数问题都能在 30 分钟内定位并修复。