20.5 大文件、大数据场景的内存控制

在 Electron 应用中处理大文件或大数据集时，如果不加控制地一次性将所有数据加载到内存，极易导致界面卡顿甚至整个应用崩溃。这一节会从实际场景出发，给出几条简单但有效的内存控制策略。

20.5.1 识别“大”的定义

“大”是一个相对概念，取决于可用内存和应用类型。但在桌面应用中，一个比较安全的参考线是：

单个文件超过 50 MB 时，应考虑流式读取，而不是 fs.readFileSync。
渲染进程显示列表或表格时，如果数据超过 1 万条，就应该考虑虚拟滚动或分页加载。
主进程中同时处理多个大文件时，注意 Node.js 默认的堆内存上限（约 2 GB 或 4 GB），超出会直接报 OOM。

20.5.2 文件读取：流式处理代替全量加载

常见误区是使用 fs.readFile 将整个文件读入内存再处理。对于大文件，应改用可读流。

const fs = require('fs');
const readline = require('readline');

// ❌ 错误做法：一次性读入，内存占用等于文件大小
const data = fs.readFileSync('large.csv', 'utf8');

// ✅ 流式逐行读取，内存占用恒定
async function processLargeFile(filePath) {
  const rl = readline.createInterface({
    input: fs.createReadStream(filePath, { encoding: 'utf8' }),
    crlfDelay: Infinity,
  });
  for await (const line of rl) {
    // 逐行处理，不会积累所有行
  }
}

对于二进制文件，可以直接使用 fs.createReadStream 并将数据管道写入写入流或进行边读边处理。

20.5.3 数据处理：流式管道和分批处理

Node.js 的 stream.pipeline 或手动管道可以让你在数据流动过程中完成转换，而不必在内存中完成整个转换。

const { pipeline } = require('stream');
const zlib = require('zlib');
const fs = require('fs');

// 边读边解压边写入，内存中不会驻留完整文件
pipeline(
  fs.createReadStream('archive.gz'),
  zlib.createGunzip(),
  fs.createWriteStream('output.txt'),
  (err) => {
    if (err) console.error('处理失败', err);
    else console.log('处理完成');
  }
);

如果无法流式处理，可以将大数组切分成小批次，并使用 setImmediate 或 process.nextTick 将控制权交还给事件循环，避免长时间阻塞主线程。

async function batchProcess(items, batchSize = 100) {
  for (let i = 0; i < items.length; i += batchSize) {
    const batch = items.slice(i, i + batchSize);
    await heavyProcessing(batch);
    // 短暂让出事件循环，保持应用响应
    await new Promise(resolve => setImmediate(resolve));
  }
}

20.5.4 渲染进程的内存控制

渲染进程（Chromium）的内存占用比 Node.js 更容易膨胀，尤其是渲染大量 DOM 元素或持有大量 JavaScript 对象引用时。

1. 虚拟滚动

当需要展示成千上万条列表数据时，不要一次性创建所有 DOM 节点。使用虚拟滚动库（如 react-window、vue-virtual-scroller）只渲染可视区域附近的行。这能极大减少 DOM 节点数量和内存占用。

2. 及时清理引用

确保事件监听、计时器和闭包引用在组件销毁或被替换时释放：

// 使用 WeakMap 或手动置 null 避免不必要的引用保持
const largeDataCache = new Map();

// 当不再需要时
largeDataCache.clear();

// 如果使用了 Blob 或 ArrayBuffer，显式释放
URL.revokeObjectURL(objectUrl);

3. 使用 Worker 或主进程分担计算

复杂的计算（例如解析大 JSON 或图像处理）应放在 Web Worker 或主进程中执行，避免阻塞渲染线程，同时也可以利用主进程拥有独立内存空间的优势，防止渲染进程堆增长失控。

// 渲染进程
const result = await ipcRenderer.invoke('process-large-json', filePath);

20.5.5 内存监控与泄漏排查

开发时可以利用 Electron 内置的 DevTools 和 Node.js 工具进行监控：

渲染进程：打开 DevTools → Memory 面板，使用 heap snapshot 对比操作前后的内存快照，查找仍在引用的对象。
主进程：使用 process.memoryUsage() 打印内存指标，或借助 v8.getHeapStatistics() 获取更详细的信息。也可以在启动时添加 --inspect 参数，用 Chrome 的 Node.js 调试工具连接。

// 主进程中定期输出
setInterval(() => {
  const { rss, heapUsed } = process.memoryUsage();
  console.log(`RSS: ${(rss / 1024 / 1024).toFixed(1)} MB, Heap: ${(heapUsed / 1024 / 1024).toFixed(1)} MB`);
}, 30000);

对于生产环境的内存泄漏，可以接入 @electron/remote 或 crashReporter 收集堆快照（需注意隐私），但更实际的做法是在开发阶段就通过模拟大数据场景的测试来暴露问题。

20.5.6 实用经验清单

永远优先考虑流：无论是文件读写、网络请求还是压缩解压，优先寻找 Stream API。
限制并发：同时处理大量文件时，用 p-limit 或自定义队列控制并发数，防止瞬间内存峰值。
及时销毁临时对象：大字符串、大 Buffer 在处理完后赋予 null，让 GC 尽早回收。
分片读取数据库：对于本地 SQLite 等数据库，不要 SELECT * 全量拉取，使用分页或游标逐条读取。
警惕 IPC 传输：通过 ipcRenderer.send 传递大数据时，数据会被序列化并复制到另一进程，无意中内存翻倍。对大体积数据，优先考虑传递文件路径，让主进程自己读取。

大文件和大数据场景下的内存控制并没有黑魔法，核心原则只有两条：能不持有就不持有（流式处理），能分担就分担（多进程、Worker）。加上适当的监控习惯，你的 Electron 应用就能稳如磐石地处理远超自身体积的数据集。