ServeStatic

为Python web应用提供生产级别的静态文件服务器。

是WhiteNoise的一个分支，用于持续维护和功能更新。

通过几行配置，ServeStatic 允许您的Web应用提供自己的静态文件，使其成为一个可以部署到任何地方的独立单元，无需依赖于nginx、Amazon S3或任何其他外部服务。这在Heroku、OpenShift和其他PaaS提供商上特别有用。

它旨在与CDN良好协作，以适应高流量网站，这样您就不必为了简单而牺牲性能。

ServeStatic 可与任何ASGI或WSGI兼容的应用程序一起使用，但针对Django有一些特殊的自动配置功能。

ServeStatic 会自动处理最佳实践，例如

• 提供压缩内容（gzip和Brotli格式，正确处理Accept-Encoding和Vary头）
• 在不会更改的内容上设置远期缓存头

担心使用Python提供静态文件效率低下？仍然认为您应该使用Amazon S3？请查看下面的常见问题解答。

常见问题解答

使用Python提供静态文件不是效率低下吗？

简短的回答是，如果您关心性能和效率，那么您应该在CDN（如CloudFront）后面使用ServeStatic。如果您这样做，由于ServeStatic发送的缓存头，绝大多数静态请求将由CDN直接提供，而不触及您的应用程序，因此ServeStatic的效率并不是很重要。

话虽如此，ServeStatic效率很高。因为它只需要提供一组固定的文件，所以所有查找文件和确定正确头部的初始工作都在初始化时完成。然后可以通过简单的字典查找来提供请求，以找到相应的响应。此外，当与gunicorn（以及大多数其他WSGI服务器）一起使用时，将文件推送到网络接口的实际业务由内核的高效sendfile系统调用处理，而不是Python。

我应该使用Django-Storages等工具将静态文件推送到S3吗？

不，您不应该这样做。这种方法的主要问题是Amazon S3目前无法选择性地向用户提供压缩内容。压缩（使用老式的gzip或更现代的brotli算法）可以显著减少CSS和JavaScript所需的带宽。但是，为了正确执行此操作，服务器需要检查请求的Accept-Encoding头部以确定支持的压缩格式，并返回适当的Vary头部，以便中间缓存知道执行相同的操作。这正是ServeStatic所做的，但Amazon S3目前没有提供执行此操作的方法。

处理静态文件的基于推入的方法的第二个问题是，它会增加部署过程的复杂性和脆弱性：特定于您的存储后端的额外库、额外的配置和身份验证密钥，以及必须在部署的特定点上运行的额外任务，以便一切正常工作。使用ServeStatic采取的CDN作为缓存代理的方法，只有两处配置：您的应用程序需要CDN的URL，而CDN需要您的应用程序的URL。其余的都是标准的HTTP语义。这使得您的部署更简单，您的生活更轻松，您也更快乐。

当我在几行apache/nginx中做同样的事情时，ServeStatic有什么作用呢？

这里有两个答案。一个是ServeStatic旨在在不容易获得apache、nginx等软件的情况下工作。但更重要的是，很容易低估正确提供静态文件所涉及的内容。您的几行nginx配置是否区分了可能改变和永远不改变的文件，并适当地设置了缓存头？您是否添加了正确的CORS头，以便字体在通过CDN提供时正确加载？您是否启用了特殊的nginx设置，允许它对HTTP/1.0请求发送gzip内容，而CloudFront出于某种原因仍然使用它？您是否安装了允许您为现代浏览器提供brotli编码内容的扩展？

这些都是微不足道的事情，但它很麻烦且令人讨厌，而ServeStatic会为您处理所有这些。