为Electron的net.request设置自定义连接超时的实现方法

问题背景 #

Electron 官方推荐渲染进程使用net.request发起网络请求，该能力基于Chromium原生网络栈实现，可自动继承系统代理、证书校验等网络配置，相较原生fetch、XMLHttpRequest兼容性更强。但该API目前未暴露直接的请求超时配置项，当目标主机不可达时，请求会默认遵循操作系统TCP层的连接超时规则（通常约60s）才触发失败回调，等待周期过长。

不少开发者会选择用定时器搭配Promise.race实现超时控制，但这类方案存在明显缺陷：

• 定时器触发超时判定后，后台挂起的请求不会被主动销毁，会持续占用网络连接资源，长期运行容易出现请求堆积
• 后续请求异步返回的error、response事件，会在Promise已经处于终态后重复触发回调，抛出未捕获的Promise异常
• 独立定时器没有和请求生命周期绑定，若请求提前结束但未清理定时器，会造成内存泄漏

优化实现思路 #

不需要完全依赖黑盒式的Promise竞速，核心是把超时逻辑和请求本身的生命周期深度绑定，让超时行为能真正控制后台请求的执行，具体逻辑包括三点：

• 创建请求时同步启动超时定时器，到达超时阈值后，立刻调用请求实例提供的abort()方法主动中断连接，从根源上清理挂起的后台请求
• 给Promise增加终态锁，确保无论后续触发什么异步事件，Promise只会被resolve或reject一次，不会重复执行回调
• 请求在任意正常结束分支（成功读取完响应、触发请求级错误、读取响应流报错），第一时间清除关联的超时定时器，避免资源泄漏

改造后的可用代码：

// 自定义超时阈值，示例为10秒
const REQUEST_TIMEOUT = 10 * 1000;
const resData: string = await new Promise((resolve, reject) => {
  let isSettled = false;
  let req: Electron.ClientRequest;

  // 初始化超时定时器
  const timeoutId = setTimeout(() => {
    // 到达超时时间：主动中断挂起的请求
    req.abort();
    if (!isSettled) {
      isSettled = true;
      reject(new Error(`Request exceeded ${REQUEST_TIMEOUT}ms timeout`));
    }
  }, REQUEST_TIMEOUT);

  req = net.request({
    method: "POST",
    url: url,
  });

  req.setHeader("Content-Type", "text/xml");
  req.write(xml);

  req.on("response", (response) => {
    resCode = response.statusCode;
    let responseBuffer = "";
    // 收集分块的响应内容
    response.on("data", (chunk) => {
      responseBuffer += chunk.toString();
    });
    response.on("error", (e) => {
      if (isSettled) return;
      isSettled = true;
      clearTimeout(timeoutId);
      reject(e);
    });
    // 响应流读取完成后返回完整内容
    response.on("end", () => {
      if (isSettled) return;
      isSettled = true;
      clearTimeout(timeoutId);
      resolve(responseBuffer);
    });
  });

  req.on("error", (e) => {
    if (isSettled) return;
    isSettled = true;
    clearTimeout(timeoutId);
    reject(e);
  });

  req.end();
});

方案对比优势 #

和单纯的Promise.race实现相比：

• 超时触发后会主动销毁挂起的请求连接，不会残留后台僵尸请求造成资源浪费
• 全链路绑定定时器清理逻辑，不存在定时器泄漏风险
• 通过终态锁拦截所有重复触发的回调，不会出现未捕获的Promise警告

注：调用abort()触发的请求error事件会被终态锁自动拦截，不会造成重复reject的问题。

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