部署新版本后Firebase App Hosting返回304 (Not Modified)问题求助

问题根源 #

Firebase App Hosting的默认缓存规则：对带内容哈希的静态资源（比如Angular打包后的main.[hash].js）设置长缓存，对index.html这类入口文件本应设置短缓存或不缓存，但出现304的情况，要么是App Hosting对入口文件的缓存规则异常，要么是浏览器本地缓存的旧index.html未正常失效。

解决办法 #

1. 确认Angular打包的哈希配置 #

确保Angular打包时给所有静态资源加上内容哈希，避免新旧资源文件名冲突。检查angular.json配置：

{
  "projects": {
    "你的项目名": {
      "architect": {
        "build": {
          "options": {
            "outputHashing": "all"
          }
        }
      }
    }
  }
}

这个配置会让JS、CSS、图片等资源文件名带上唯一哈希，新版本资源绝对不会被旧缓存命中。

2. 强制刷新与前端版本提示 #

• 部署后，让用户执行强制刷新（Windows/Linux：Ctrl+Shift+R；Mac：Cmd+Shift+R），直接绕过本地缓存拉取最新资源。
• 可以给Angular入口index.html添加版本元标签：

<meta name="app-version" content="v1.0.1">

前端可定时检查该版本（比如和后端接口返回的版本对比），提示用户刷新，适合需要自动处理缓存失效的场景。

3. 联系Firebase支持调整缓存规则 #

由于Firebase App Hosting不支持firebase.json自定义缓存设置，如果默认规则不符合你的单页应用需求，直接联系Firebase官方支持，说明你需要给index.html设置严格的缓存控制头，比如Cache-Control: no-cache, no-store, must-revalidate，确保浏览器每次都请求最新入口文件。

关于if-modified-since头的说明 #

浏览器发送if-modified-since: Tue, 01 Jan 1980 00:00:01 GMT这种特殊日期，一般是因为之前服务器未返回Last-Modified头，或者本地缓存的资源Last-Modified被设为这个旧日期，导致服务器判断资源未修改返回304。解决入口文件的缓存控制问题后，该现象会自然消失。

内容的提问来源于stack exchange，提问作者ievgen