connect.static中间件是否被认为足够强大，可以提供不仅仅是样式表和脚本的静态内容？
（我正在考虑提供大量图像文件等情况）。
或者更适合运行“标准”网络服务器，如nginx，以及静态内容？
答案 0 :(得分：4)
加载问题的排序。它没关系，直到它没有。
这些静态中间件是大多数动态站点的便捷方法。您可以随时切换到使用Node.js-based static content server，然后再使用NginX，它主要用于提供静态内容，然后当这还不够时，您可以将NginX反向代理服务器设置为多个NginX服务器，如果磁盘I / O成为瓶颈，如果您的反向代理服务器无法处理传入连接的数量和/或您希望在全球范围内分发主机，您可以使用Round-Robin DNS进一步改进，并且您始终可以通过在CDN中托管静态内容来支付所有这些工程工作。
所以，做一些基准测试。您希望您的网站有多少个请求？静态与动态内容的百分比是多少？最终用户可以在第二次请求时缓存多少静态内容？这些文件平均有多大？
一旦你可以计算出“每秒4000个请求，总吞吐量为每秒30MB”这样的东西，那么你可以决定你应该为托管静态内容的滑动范围确定哪些内容。