记一次 node-fetch 使用时踩的坑
背景
在使用如下代码发起请求的时候，个别接口出现了无法得到结果的情况。
async function req() {
const res = fetch(xxx);
let resData = null;
try {
resData = await res.clone().json();
} catch (err) {}
if (!resData) {
log(await res.clone().text());
}
}
追查
首先
我通过其他请求工具，发现出问题的接口是正常响应的。也就是确认了问题是出在自己的代码里面的。
然后
我在 try 后面打断点，想看一下 resData 收到的是什么，发现程序根本走不到那，但是 try 里面也没有报错。
到这一步，我就觉得问题有点奇怪了。
接下来
我只能到 node-fetch 的代码里面去加断点看一下是什么情况了。
在这过程中又出现了很诡异的一幕。我分别在 on('data') 和 on('end') 的时候加调试信息，发现 end 事件没有触发，但如果在 on('data') 中添加断点的话，end 能够触发，而整个请求也能收到响应结果了。
通过进一步调试，我发现如果不对 node stream 的模型做一个系统的了解，我可能会很难查出问题的原因。但对于问题的解决，依稀记得之前使用 res.json() 的时候是没有问题的。
尝试解决
于是，我尝试着将 res.clone().json() 改成 res.json()，果然问题不在出现，请求顺利接收。这时候我开始怀疑是不是 node-fetch 在 clone 的实现上有 bug 。但看了看源码，思路很清晰，感觉不出哪有问题啊。所以，没有了解清楚 stream 相关的思路前，还不能妄下定论。
而对于 .json 失败后，需要记录响应文本的情况，就改用 res._convert().toString() 实现了。
原因探究
后来，我又通过一步一步断点调试和对 stream 的文档和源码的查看，终于定位了问题。
原来，node-fetch 在 clone 的时候产生了两个目标，源码如下：
p1 = new PassThrough();
p2 = new PassThrough();
body.pipe(p1);
body.pipe(p2);
// set instance body to teed body and return the other teed body
instance.body = p1;
body = p2;
然后我的代码使用了其中一个即 res.clone 的返回进行 .json 操作，相当于 p2.json()。但对另一个 res 即 p1 没有做处理。
而 stream 有一个 back pressure 机制，因为 p1 没有消耗，缓存数据满时会使其源 pause，从而导致 p2 也不能结束。
结语
- 使用 stream 时，若 pipe 了多个目标，一定要注意他们相互之间的影响。
- 对于一项技术，唯有在透彻理解其机制后，才能更好的运用。