在 Node 环境下，request 库有很多种，很容易让人挑花了眼，这篇文章主要从一些简单的维度做一个对比分析。
一、对比范畴
request
got
axios
SuperAgent
HTTP-原生node模块
二、优先排除的选项
第5项是第一个 pass 的，HTTP
和HTTPS
模块提供的大多数功能是相当有限的。我需要以区块为单位接收响应数据，而不是只提供一个回调函数，以便在收到所有数据后就立即执行。如果它是JSON格式你还需要进行手动解析。尽管工作量不大，但是它仍然会带来一些不必要的操作。另一个麻烦是，HTTP
和HTTPS
协议分属两个模块，因此如果我们使用的API是通过HTTPS
协议进行通信，则需要HTTPS
模块。但我并不想向代码库中添加太多的依赖项或希望为了使用其底层的功能而花费更多的精力。优先排除选项5
三、对比的维度
下载量：
对于一个工具库，最简单的评价角度就是，用的人多不多？
数据截止2021年06月07日
从这张图上面可以看出，在近半年的下载中: request > got > axios > superagentstar 数：
star 数上来说：axios > request > superagent > got
最近master 分支 commit时间及更新次数：
request 最新一次的 commit 是在2020年2月，但 commit 数已经没有了，如果查看 readme，你会发现官方已经不维护这个工具库了。
axios 最新一次的 commit 是在2021年5月，更新频率应该排4个仓库里面第2，还有，它拥有 facebook 的背书。
got 最新一次的提交在2021年6月，且更新频率应该是4个库里面最高的
superagent 最新的一次提交在 2021年2月，提交记录在2021年后基本没有了
上面更新频率上来做简单对比的话，两个老牌强者 superagent 以及 request 的表现均不佳。不是指他们的功能不能满足我的诉求，只是，我不太放心一个不更新维护的工具库在我的代码仓库中使用。
如果真的发现一个issue，只能自己去debug → fork → 修改 → 测试 → 发内网包 ，这个步骤可能不是我想要的。所以，在我的选型过程中，我将 superagent 以及 request 排除了出去。
四、最终的对比
到这一步，其实也有点出乎我自己的预料，我比较看重2个点：
工具库的维护以及活跃程度
功能要足够强大，api 要足够好用
第一点上文的第三部分已经简单分析了，got 与 axios 其实相差不大。
但 axios 的 star 数是 got 的 9 倍，再加上我在写前端 js 项目的时候，已经习惯了 axios 的用法，所以，我很想当然的选择了 axios 。
但是，它第一天就给了我一个下马威。场景是这样的，我需要在 node 服务请求内网其他服务，返回404状态码的时候，再重试一次，但是，axios 原生并没有提供 retry 的 api，这让我心里产生了嘀咕：“不应该啊”
所以，我开始重新审视 got 与 axios，从 issue 这个点开始切入吧。先看一个简单的未关闭 issue 以及 issue label 标签对比：
| open issue | label | |
| axios | 141 | 28 |
| got | 51 | 19 |
axios 目前已经确认的 bug 只有 5 个：
got 目前已经确认的 bug 是它的 2 倍，一共有10个：
从两个仓库的更新频次开看，我会认为两个仓库的维护者都很棒，投入了很多精力在这两个仓库上。
来对比一下两个仓库提供的功能，哦，一下子发现了新大陆了~
完整看下这张表，你会发现基本上 got 的功能是最齐全，但是其安装包反而不是最大的，对于一个 node 服务来说，我要的就是快而且好用，既然都支持 promise api，并且能够完美支持TypeScript，何乐而不为呢？而且回到开头的下载量，你会发现 got 的下载量可是超过 axios 的，还有一点，要特别注意，got 只支持 node，不支持在浏览器里面使用，而 axios 是两种都支持的，我是不是可以简单的推断，其实在 Node 端，got 更加适用？
这是在我初次尝试将 Node BFF 引入当前公司技术体系所做的一小部分工作，等待 BFF 完成，我没有办法确认这个选型一定是当前最优，只能用今天上海高考的作文题目来反思自己的做法，“让时间来沉淀”，挖个坑，也许三个月我就后悔了呢？到时候来重新编辑该文章，哈哈哈哈~
