2026-08 假设你想做一个网页项目，打算让其他人自己在他们的服务器上托管。不幸的是，想到这个想法后，你立即将你的代码库锁定在几种其他软件可以利用的效率技巧之外，而且你现在不得不重新发明几个别人已经做得更好的轮子。让我们从一个基线开始，随着需求的变化而添加：一些与应用程序分开处理 TLS 的东西，这样你的私钥就不会暴露得比必要的更广泛，并且让你可以更改获取证书的方式，而不影响应用程序代码。这个应用程序在几乎所有情况下，第一部分可能也会是一个相对强大的网络服务器，包含反向代理作为许多功能之一。一个非常常见的功能是提供静态文件，这目前由你的应用程序处理。将静态文件转交给反向代理并不是一个坏主意。它的实施可能比你选择的热门新框架自带的更好，即使不是，静态文件将不再阻塞你的 Python 或 Node 网络服务器同时处理的平庸请求量。你尝试这样做。如果你的应用程序或反向代理被容器化或以其他方式进行隔离，现在每个设置你应用程序的管理员都需要在这一个或两个隔间中打一个洞，以便让反向代理访问与应用程序一起分发的静态文件。当你的应用程序最终发布时，你收到一份来自某个反向代理用户的问题报告，他的反向代理是那种“云原生”的，只执行反向代理，并且仅作为 Kubernetes 的一部分分发。你沮丧地添加回一个选项，允许应用程序提供文件，所有人一旦意识到它的存在，立刻开启。你哭泣，因为你意识到你已增加了低端硬件潜力的效率损失，这是你的目标受众所能接触到的。在“专业”规模上？静态文件完全分开部署，可能放在 S3 桶或类似的地方，并通过一个真正的 CDN™ 进行前置，因此这个问题根本不会出现。未认证的缓存你意识到你的应用程序会收到很多未认证的访问，无论是来自人类还是机器人。未认证的访问总是得到相同的响应，因此如果没有任何变化，实际上没有理由重新计算这些响应。你确定一个小时对于你所处环境的“陈旧”页面是一个合适的时间。你怀着深情的目光看着 Vinyl 缓存网站，心中明白你不能真正要求它，因为你只是托管者的网络服务器中已存在的 Rube Goldberg 机器中的一部分。沮丧之下，你向你的端点添加必要的 Cache-Control 和 Vary 头。你发现了 no-vary-search 并意识到这只是 Chrome 专属。你知道会改变响应的确切查询参数集，但你从你所处的位置无能为力。如果你能够依赖 Vinyl，你可以剔除未使用的查询参数，从而避开那些试图复活关于链接预览的死笑话的人，导致他们在你的链接后添加 ?qweqweawe 来绕过缓存。你发现你的 Web 服务器库有一个缓存中间件。你阅读了它支持的功能，并意识到它支持的仅限于 Cache-Control 的 TTL ，或许如果你幸运的话还有 Vary。你将其添加进来，心中仅抱有一丝希望，不希望有人尝试一些有趣的事情。你放置了一个配置开关和文档，希望已经设置好良好缓存的管理员可以把它调整到最佳效率。但他们没有。在你的应用程序发布后，你收到来自 Caddy 用户的反馈，因为他们信任 Caddy 超级平庸的缓存插件，如果它觉得合适就乐于破坏响应。还有其他人启用了 Nginx 的缓存，但他们的安装仍然变得缓慢，因为他们忘记启用 proxy_cache_lock。还有人将自己的网站放在 Cloudflare 后面，但同时启用了你的缓存选项，因为他们自己机器上没有设置缓存。你对浪费的内存感到心痛。你还意识到你内置的缓存中间件正在缓存你的静态文件。提供这些文件相对简单，并且可能已经被你操作系统的磁盘缓存设施缓存，所以你只是白白增加了内存开销。因为你的中间件只查看 Cache-Control，所以如果不妨碍浏览器在客户端上缓存你最佳实践的不可变静态文件，你就无法做任何事情。你哭泣。在“专业”规模上？他们可以控制整个机器，因此他们确实可以设置 Vinyl 或类似的东西，并将其调整到他们想要的确切缓存行为。好吧，可能他们把它外包给一个做着平庸工作的 CDN，但他们有选项可以如此细粒度地控制缓存。已认证的缓存你意识到你的应用程序可能会...