新鲜的（参见第4.2节），或
允许过期的（参见第4.2.4节），或
成功验证的（参见第4.3节）。
由于您输出的Expires标头在遥远的将来，且该时间尚未到达，因此响应是“新鲜的”，因此不需要重新验证。因此，您在自己的端上做了规范建议的一切。（虽然使用“Cache-Control：max-age=foo”比使用“Expires：”标头设置缓存到期时间更现代化）。
因此，如果您想更改浏览器的缓存行为，则没有希望可言。
然而，情况可能没有你想的那么糟糕。你可能只是在测试时在浏览器中刷新页面，因此只看到了一个请求和304响应。浏览器根据触发它们的请求方式来处理缓存资源。
我进行了一个简单的测试，创建了一个包含指向JS文件的<script>标签、指向图片的<img>标签和指向CSS样式表的<link>标签的HTML页面。这些文件都托管在配置为使用以下设置提供服务的Apache服务器上：
Cache-Control: max-age=172800头文件显然，在首次加载页面时，所有资源都以200代码提供服务。此后，在Chrome或Firefox安装默认设置的测试中，我发现：
这个页面表明Internet Explorer有相同的行为：
有许多情况下，Internet Explorer需要检查缓存条目是否有效：
- 缓存条目没有到期日期，并且在浏览器会话中首次访问内容
- 缓存条目具有到期日期，但已过期
- 用户通过单击“刷新”按钮或按F5键请求页面更新。
换句话说，通常情况下，只有在用户明确刷新页面时才会看到这些重新验证请求。除非您对浏览器缓存的行为有特别要求，否则此行为似乎完全合理。
Google和Mozilla都有一些关于HTTP缓存的文档（我找不到任何等效的MSDN或苹果开发者网站），但没有建议存在任何供应商特定的缓存标头可用于修改浏览器选择何时重新验证的规则。你想做的根本不可能。
如果您真正需要更多控制此行为的方法，可以研究HTML5应用程序缓存或使用HTML5本地存储自己的缓存逻辑，例如 basket.js所做的那样。
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpErrors errorMode="Detailed" />
<rewrite>
<rules>
<rule name="Angular Routes" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="/NameOfYourApp_UnderDefaultWebSite/" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
<action type="Rewrite" url="/NameOfYourApp_UnderDefaultWebSite/" /> 中 url 的值。Expires:或Cache-Control: max-age=应该可以解决问题。您是否在服务器日志中确认浏览器实际上正在进行网络调用？我发现例如Firebug的输出很令人困惑，它会让你误以为你正在进行远程调用，而实际上你只是在访问缓存。
Last-Modified时间正确的一个好理由是：不要伪造时间来规避问题。 - Jake有一条规则，将 Expires 头设置在超过一年的未来时间会违反HTTP 1.1 RFC。
因此，这里的 HTTP 响应头是无效的（Expires: Tue, 19 Jan 2038 03:14:07 GMT）。修复此问题可能会解决该问题！
2038年1月17日19:14:07 GMT，因为这是32位Unix时间/日期格式支持的最大值。你的日期比这晚了几天，也许这就是原因... - user1429080tools.ietf.org，我会把它加入书签。关于过期头信息：如果未来日期实际上是问题的原因，我会感到惊讶，但既然我发现了它，我认为应该提一下... - user1429080