我应该在新项目中使用“请求”模块吗？

The “请求”模块 https://github.com/request/request长期以来一直是 Node.js 的标准。他们最近已弃用 https://github.com/request/request/issues/3142图书馆。

我正在开始一个新项目，并寻找最好的解决方案来建立我的网络。我开始使用本机“https”模块 https://nodejs.org/api/https.html，但遇到了一个又一个问题。使用request模块似乎很简单并且工作得很好。还有很多其他图书馆 https://github.com/request/request/issues/3143来替换request module.

一般来说，您应该尽可能避免使用已弃用的库。但这个经验法则在这里适用吗？

使用“请求”模块开始一个新项目是否不好？如果是的话，新标准是什么？

我个人不会开始一个新项目request()库，除非它具有我绝对需要的其他库所没有的功能，或者除非我需要另一个依赖于该库的模块request()模块本身。

当我有选择的自由时，我会使用got() https://www.npmjs.com/package/got而是用于新项目。选择从替代方案清单 https://github.com/request/request/issues/3143这是个人决定，因此您只需评估它们各自具有的界面类型以及它们具有哪些功能。对于我通常使用这种类型的库所做的事情，got()看起来简单干净，从头开始构建，有承诺，满足我的需求，而且我使用它没有任何问题。

Axios https://www.npmjs.com/package/axios, 节点获取 https://www.npmjs.com/package/node-fetch and 超级代理人 https://www.npmjs.com/package/superagent优点是您可以在 Node.js 和浏览器中使用类似的界面。所有这些都很受欢迎并且被广泛使用。

I tried bent https://github.com/mikeal/bent，但没有点击它的编程界面。

我个人更愿意使用那些明确目标是随着语言的新发展、nodejs 库的新发展而不断发展并随着时间的推移添加新功能的库，而不是声称不会添加新功能的库。

我还喜欢使用从核心内置 Promise 支持的库，而不是仅作为包装器添加，因为我现在使用 Promise 进行所有异步编程。

检查替代方案的一些其他资源：

功能对比图 https://github.com/sindresorhus/got#comparison（由制作者撰写got())

从 request 迁移到 get() https://github.com/sindresorhus/got/blob/main/documentation/migration-guides/request.md

而且，如果您想了解为什么request()图书馆已进入维护模式，请阅读here https://github.com/request/request/issues/3142.

简而言之，它是一个旧的架构，侧面粘有大量功能，但由于有太多模块依赖于它，因此他们无法真正破坏其 API 来修复或平滑问题。而且，由于它如此受欢迎，它阻碍了设计更简洁界面的竞争解决方案的成功。因此，我们决定让以更现代的方式设计的替代方案继续前进，request()将进入维护模式以继续支持依赖于它的其他模块，但不会尝试演变为更现代的界面。