connect.static中间件是否被认为足够健壮，可以提供不仅仅是样式表和脚本的静态内容
（我想到了一些情况，比如提供大量的图像文件）。
或者运行一个"标准"Web服务器（如nginx）来处理静态内容更合适吗
有点像一个加载的问题。它很好，直到它不是。
这些静态中间件是大多数动态站点的方便方法。您总是可以切换到使用基于Node.js的静态内容服务器，然后进一步切换到NginX，它主要为静态内容服务，然后当这还不够时，如果磁盘I/O成为瓶颈，您可以为几个NginX服务器设置一个NginX反向代理服务器，如果你的反向代理服务器无法处理传入连接的数量和/或你想在全球范围内分发托管，你可以使用Round Robin DNS来进一步改进，并且你可以通过在CDN中托管静态内容来支付所有这些工程工作的费用。
所以，做一些基准测试。你希望你的网站有多少请求？静态内容与动态内容的比例是多少？最终用户在第二次请求时可以缓存多少静态内容？这些文件平均有多大？
一旦您可以计算出类似"每秒4000个请求，总吞吐量为每秒30MB"的数据，那么您就可以决定应该在托管静态内容的滑动范围内进行构建。