在节点中，如果有人确实使用 IncomingMessage 选项，则昨天提交的 nodejs/node@a899576c 可能会给 express 带来重大问题。
在请求https://github.com/expressjs/express/blob/master/lib/request.js#L31的第 31 行，express 引用了 http.IncomingMessage.prototype 来扩展它的所有 express 功能。
如果有人更改了 http IncomingMessage 类并且不扩展 IncomingMessage，那么 reqs 将不具有任何 express 功能。
不确定为什么有人会这样做，但他们可以选择复制整个类而不必扩展真实的类。
我还没有测试过这个（我需要学习如何构建节点）..但我想让大家注意一下。
非常有趣。我想知道我们是否可以对 Express 进行一些更改来弥补这一点（理想情况下是向后兼容旧版 Node.js 和人们现有的应用程序）？我想知道 Node.js 核心是否意识到了这一点；毕竟 Express.js 仍然是 Node.js 基础的一部分 :D
我确实认为我们需要在这里删除原型继承。我认为这应该是 的要求5.x。不仅因为这个问题，还因为替换原型是一个性能问题（也是我的新雇主不使用 express 的原因之一，以及路由器中的递归）。
我发起了一个 PR，至少将当前方法提取到单独的模块中，但我真的认为它需要更进一步。鉴于这些 api 的相对稳定性，我认为用我们自己的req/包装它们的维护成本res不会那么多。
我现在正在上班，所以不能花太多时间写这个，但我对此有很多想法。
以及路由器中的递归
路由器上的递归是什么？这不是在很多版本之前就被删除了，以解决 Netflix 文章的问题吗？一定要打开一个关于这个问题的问题，这样才能解决它/至少让人们知道它 :) @wesleytodd 你现在甚至是一个 Express 成员了，哈哈
我现在正在上班，所以不能花太多时间写这个，但我对此有很多想法。
请务必分享 :)！ Express 5.x 是我们做出重大改变的开端。如果您也想聚在一起集思广益，我很乐意安排一些事情。
我想到的是那篇文章https://medium.com/netflix-techblog/node-js-in-flames-ddd073803aa4，该文章已在 2015 年 1 月的 Express 4.11.0 中修复。
是的，这就是我所引用的文章，据我所知，我们的情况比以前好多了，但 restify 采取了不同的方法，有利有弊。现在正在开会，但我想写下我从 Netflix 的人那里听到的所有事情，这些事情可以帮助我们改进和推动 express 的发展 :)
太棒了，@wesleytodd 期待着。我不知道你现在在 Netflix 工作，恭喜！我们有https://github.com/expressjs/discussions存储库，可以作为总体规划讨论的场所，对于跨多个存储库的项目特别有用。
更换原型是一个性能问题
虽然这是我在使用 Express 之前完成的，但最终这种方法比 Restify 更好，Restify 实际上会全局修补 Node.js 内部对象（https://github.com/restify/node-restify/blob/master/lib/server.js#L33-L34），从而影响在同一进程中运行的所有 http 服务器。如果我必须在 Express 当前添加糖的方式和 Restify 当前添加糖的方式之间做出选择，我会说 Express 这样做更好。它们都很糟糕，不要误会，只是比较一下，在我看来 Express 目前是最不糟糕的，哈哈。
是的，我同意 restify 的做法也不好。实际上，我认为 restify 做的很多事情都比 express 差。但据我所知，有些性能方面，它们可以证明自己做得更好。我希望我们能找到一个更好的中间立场，既有 express 的实现优势，又有 Netflix 所依赖的性能优化。
我刚刚联系了那篇文章的作者，他现在还在 Netflix，想看看能否向他请教。所以，看看我能否实现这个愿望。
明白了。是的，Express 愿意做出必要的改进。最大的障碍是甚至不知道他们能做什么。这是企业和开源世界之间的一个常见障碍（我也在企业界，所以我肯定知道）：公司内部的员工会用开源软件做很多事情，比如发现错误、怪癖、相互评估不同的解决方案。但最终，这些发现从未在公司外部被谈论过，或者现在充其量只是就这个话题发表了一篇过于笼统的工程公关帖子。
性能比较甚至更加困难，因为很多时候负责这项工作的员工根本不了解他们所测试的内容（可能只非常了解其中一项）。我曾亲自监督过一个团队进行性能测试，他们测试了两个部分，但测试结果比其他部分低得多，因为他们犯了一个编码错误，因为他们没有阅读任何文档，只是在 Google 上搜索，快速拼凑了代码 :) 我不是说所有代码都是这样，但即使发布了总结，也很难知道，因为它们通常不包括重现基准的方法。
因此，事实证明，该 PR 到节点核心的原始作者是 Netflix 的团队成员，特别是因为 Restify 不需要破坏核心req/ res。@dougwilson 我将着手撰写一些文章，探讨 restify 和 express 之间的差异，以及我们如何合作和共同努力的提案。我会将其发布在讨论存储库中，并在取得进展时链接回这里。
很好，期待它：+1：看着提交，我认为 express 不可能使用它，因为 Express 被设计为仅传递一个 req 和 res 对象，这使得 Express 可以灵活地嵌入到 Hapi 服务器、Koa 服务器、Connect 服务器等中。该提交对于不允许这样做的框架来说看起来很有用，而是创建底层 HTTP 服务器，例如 Hapi 和 Restify。