Electron中fs.createReadStream传大文件致PeerJS WebRTC通道阻塞

• 流读取无背压控制：给fs.createReadStream绑定data事件后，流会进入流动模式，无视下游IPC、WebRTC通道的消费能力，按磁盘读取速度持续吐出数据块，上游读速度远快于网络发送速度，数据全部堆在本地缓冲区。
• 多层通道无流控反馈：
  1. Electron主进程的webContents.send没有背压机制，持续推送的数据块会全部塞进渲染进程的IPC消息队列，事件循环被密集的IPC消息占满，网络IO回调没有执行机会；
  2. WebRTCRTCDataChannel的send()方法不会等数据真正发出去再返回，数据会先存在本地发送缓冲区，无节制调用send()会让缓冲区持续膨胀，超过阈值后要么阻塞事件循环，要么触发WebRTC栈的连接保护机制断开连接，这就是大文件传输断连的核心原因。
• 之前的unblockTask方案完全无效：该逻辑只是把send()操作挪到宏任务队列，既没有控制读取速度，也没有感知缓冲区状态，反而会堆积大量定时器任务，事件循环依然被占满，必须等所有文件块读完、不再往队列塞新任务后，才会开始执行实际的网络发送逻辑，因此接收方要等发送方读完整个文件才会收到数据。
• fs.readFileSync方案能跑通是因为读取完成后手动拆块发送时，发送节奏没有被磁盘读的快速度拖垮，但整个文件存在内存中，自然无法支持大文件。

核心思路是全链路加背压控制：下游能消费多少，上游才读多少，完全杜绝无节制的数据推送。 #

1. 主进程fs流改为请求-拉动模式 #

不要让流自动吐数据，改成渲染进程请求一块、主进程读一块返回，从源头控制读取速度：

// icpMain_process.js
let readStream = null;
let isReading = false;
// 建议块大小设置为16KB~64KB，匹配WebRTC最佳传输单元
const DEFAULT_CHUNK_SIZE = 32 * 1024;

ipcMain.handle(READ_FILE_CHUNK_OPEN, async (event, fullFileName) => {
  // 先销毁之前存在的流
  if (readStream) {
    readStream.destroy();
    readStream = null;
  }
  // 创建流时默认进入暂停模式，不绑定data事件
  readStream = fs.createReadStream(fullFileName, {
    highWaterMark: DEFAULT_CHUNK_SIZE,
    autoDestroy: true
  });
  isReading = false;

  // 移除之前全局绑定的READ_FILE_CHUNK_NEXT监听，避免重复绑定
  ipcMain.removeHandler(handlerName.READ_FILE_CHUNK_NEXT);
  ipcMain.handle(handlerName.READ_FILE_CHUNK_NEXT, async () => {
    if (!readStream || isReading) return { chunk: null, isEnd: false };
    isReading = true;
    return new Promise((resolve, reject) => {
      const onReadable = () => {
        const chunk = readStream.read();
        if (chunk) {
          cleanup();
          isReading = false;
          resolve({ chunk, isEnd: false });
        }
      };
      const onEnd = () => {
        cleanup();
        readStream = null;
        resolve({ chunk: null, isEnd: true });
      };
      const onError = (err) => {
        cleanup();
        readStream = null;
        reject(err);
      };
      const cleanup = () => {
        readStream.off('readable', onReadable);
        readStream.off('end', onEnd);
        readStream.off('error', onError);
      };
      readStream.once('readable', onReadable);
      readStream.once('end', onEnd);
      readStream.once('error', onError);
      readStream.read();
    });
  });
});

2. WebRTC发送端加缓冲区背压控制 #

监听数据通道的缓冲区状态，只有缓冲区低于安全阈值时才发送下一块，不要无脑调用send()：

// peerjs_data.js
const BUFFER_THRESHOLD = 256 * 1024; // 发送缓冲区最大阈值256KB
let sendQueue = [];
let isSending = false;
let peerjs_dataconnection = null;
let currentSeq = 0;

// 数据通道初始化时配置参数
function initConnection(conn) {
  peerjs_dataconnection = conn;
  // 设置缓冲区低水位触发阈值
  peerjs_dataconnection.bufferedAmountLowThreshold = BUFFER_THRESHOLD;
  // 缓冲区降到低水位时自动继续发队列里的剩余数据
  peerjs_dataconnection.on('bufferedamountlow', () => {
    sendNext();
  });
  peerjs_dataconnection.on('close', () => {
    sendQueue = [];
    isSending = false;
    currentSeq = 0;
  });
}

// 主动向主进程拉取块，不要等主进程推
async function startSendFile(fileTotalSize) {
  let isEnd = false;
  currentSeq = 0;
  while (!isEnd) {
    const { chunk, isEnd: endFlag } = await ipcRenderer.invoke(handlerName.READ_FILE_CHUNK_NEXT);
    isEnd = endFlag;
    if (chunk) {
      // 这里替换成你自己的封包逻辑，记得加序号保证接收端顺序
      const packet = { type: 'file_chunk', seq: currentSeq++, data: chunk };
      sendQueue.push(packet);
      sendNext();
    }
    if (isEnd) {
      sendQueue.push({ type: 'file_end', totalSize: fileTotalSize });
      sendNext();
      break;
    }
  }
}

function sendNext() {
  if (isSending || !peerjs_dataconnection) return;
  isSending = true;
  while (sendQueue.length > 0) {
    // 缓冲区超过阈值就停止发送，等bufferedamountlow事件触发再继续
    if (peerjs_dataconnection.bufferedAmount > BUFFER_THRESHOLD) {
      break;
    }
    const packet = sendQueue.shift();
    peerjs_dataconnection.send(packet);
  }
  isSending = false;
  // 兜底检查，避免错过发送时机
  if (sendQueue.length > 0 && peerjs_dataconnection.bufferedAmount <= BUFFER_THRESHOLD) {
    sendNext();
  }
}

// 完全删除之前的unblockTask方法，不需要setTimeout做假异步

补充注意点 #

• 禁止用setTimeout/setInterval做流控：定时器无法感知真实的网络状态和缓冲区占用，要么浪费带宽要么依然会造成阻塞。
• 接收端同样用流式写入：收到数据块后按序号通过fs.createWriteStream写入磁盘，不要把所有块存在内存里拼接，避免接收端内存溢出。
• 块大小不要超过64KB：WebRTC数据通道的默认最大传输单元适配16-64KB的块，过大会增加拆包开销，过小会增加协议头占比浪费带宽。
• 该方案下发送端、接收端的内存占用始终稳定在几百KB级别，传输几十GB的文件也不会出现内存上涨或连接断开问题。

内容的提问来源于stack exchange，提问作者user3792705