Node.js使用Promise封装https.request请求的异常处理问题

核心问题修复：为什么catch块打印的e为空 #

你遇到的catch输出空不是reject没有生效，是JSON.stringify处理Error对象的特性导致的：JavaScript内置Error对象的message、stack等属性都是不可枚举属性，JSON.stringify默认只会序列化可枚举的自有属性，所以JSON.stringify(new Error('statusCode=404'))的结果就是{}，看起来像空对象。
你把catch里的打印改成直接输出e或者e.message就能看到完整错误信息：

.catch((e) => {
  console.log("错误信息：", e.message ?? e);
});

三个reject分支的合理性 #

这三个分支完全对应HTTPS请求全链路的三个不同错误阶段，都是必要的，不是冗余代码：

1. 状态码非2xx时的reject #

对应「请求正常发送到服务端、服务端也正常返回响应，但响应状态码代表业务/接口错误」的场景，比如404接口不存在、500服务端内部错误、401鉴权失败等。你这里主动new Error封装错误信息是合理的，不是多余操作。

2. JSON.parse catch块里的reject #

对应「服务端返回了正常的2xx响应，但响应内容不是合法JSON格式」的场景，比如服务端出错返回了HTML错误页、接口返回了纯文本字符串、编码错误导致乱码等，都会触发JSON.parse抛出异常。

这里你有个小bug：reject之后没有加return，虽然Promise状态一旦变更就不会再修改，但是加上return可以避免后续多余代码执行，逻辑更严谨：

try {
  body = JSON.parse(Buffer.concat(body).toString());
} catch (e) {
  return reject(e); // 加return终止后续代码
}
resolve(body);

3. req对象error事件里的reject #

对应「请求还没发送到服务端，连接层面就失败」的场景，比如域名解析失败、网络断开、HTTPS证书校验失败、连接超时等，这种场景下根本拿不到服务端的响应，只会触发请求对象的error事件。

优化建议：这里你现在直接rejecte.message字符串，其他分支reject的是Error对象，最好统一格式，改成reject(e)方便后续统一处理错误。

代码里其他注释疑问解答 #

• var body = []; res.on("data", function (chunk) { body.push(chunk) })这段逻辑的作用：
  Node.js的HTTP/HTTPS响应是流式传输的，服务端返回的数据会拆分成多个二进制数据块（chunk）分批返回，data事件每收到一个chunk就触发一次，这段代码就是把所有收到的chunk暂存到数组里，等全部数据接收完成再统一处理。
• res.on("end")里的逻辑是不是把流数据转JSON：
  是的，Buffer.concat(body)把所有暂存的二进制chunk拼接成完整的Buffer，转成字符串之后再用JSON.parse解析成JS对象，就是最终的接口返回数据。
• req和res的区别：
  req是请求对象，代表你向外发送的HTTPS请求，用来控制请求发送、监听请求发送阶段的错误；res是响应对象，代表服务端返回的响应，用来接收响应数据、监听响应接收阶段的事件。

内容的提问来源于stack exchange，提问作者Dan N.