我在一个服务器场中使用捆绑和最小化，在该服务器场中有新旧服务器的过渡期。
我遇到的问题是旧服务器正在缓存新捆绑包缓存无效URL的内容。
例如，新的HTML与新的包URL一起缓存：
<script src="/bundle.css?v=RBgbF6A6cUEuJSPaiaHhywGqT7eH1aP8JvAYFgKh"></script>
然后，这会向尚未使用新CSS代码进行更新的旧服务器发出请求，然后将其缓存。
随后，对新bundle URL的任何后续调用将返回旧代码。
因此，有没有一种方法可以检查分发包的内容是否与散列的缓存破坏者匹配？并且如果它没有抛出例如404。
在上面的示例中，当请求返回到该捆绑包的旧服务器时，它将检查捆绑包的内容，生成内容哈希并将其与查询字符串进行比较。
在这种情况下，缓存无效器与实际的内容哈希不匹配，并且会返回404。
最终，用户将使用捆绑请求访问新服务器，并且正确的内容将被缓存。
最佳答案
我们注定很快就会遇到相同的问题，但我们一直坚持只使用2个更新域（将服务器分成两半，以便一次运行的版本不超过一个）。
据我所知，有4种可能的选择：
让您的静态内容始终指向最新的服务器。可以通过IP地址或使用您知道已经更新的URL（如果您具有首先更新的服务器）来完成（取决于您的配置）。
配置负载平衡器，以使来自同一IP地址的请求最终出现在同一系统上（如果您的静态内容是由您的应用程序服务器提供的）。如果无法在负载均衡器级别完成此操作，则可以通过为不同的环境配置不同的IP地址，然后交换其DNS记录来做进一步的工作。
在ASP.NET中实现一个侦听CSS文件的处理程序，并检查该捆绑包的哈希值是否与预期的相符。在应用加载时生成它们时，您可能需要一个singleton对象来存储它们。然后，这可以返回404、301（以使它们重试），也可以返回旧版本，但指示它不缓存结果。请注意，使用HttpPipelining，您不太可能访问其他服务器，因此重定向可能无济于事。
在执行部署时设置了一个配置标志，该标志会将所有缓存无效化URL更改为当前日期。这将有效地禁用所有缓存，直到完成部署为止，这意味着将不保留任何交付的“错误”资产。
这是您实际上遇到的问题，还是假设的问题？除非您的网站流量很高并且部署需要花费几分钟，否则您不太可能看到。您将要警惕返回404，因为有时错误的样式表总比没有样式表好。