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