代码分割块的CDN缓存机制及React部署后旧资源兼容方案咨询

一、代码分割块的CDN缓存机制 #

代码分割生成的chunk文件，通常会带上内容哈希值作为文件名的一部分（比如chunk.abc123.js），CDN对这类文件的缓存逻辑如下：

• 以文件名作为缓存标识，默认长期缓存（比如Cloudflare对静态资源的默认缓存时长可达30天以上）。因为哈希值随文件内容变化而改变，只要文件内容不变，文件名就不会变，CDN会持续返回缓存的版本。
• 不带哈希的入口文件（如index.html），一般会配置较短的缓存时长或直接禁用缓存，确保用户能获取到最新的入口文件，从而加载对应版本的chunk。
• 你遇到的问题核心在于：旧版本的chunk被Firebase Hosting替换后，CDN从未缓存过这些旧文件，当仍在使用旧版本的用户发起请求时，源站已无对应文件，最终导致加载失败。

二、业内通用的旧资源兼容实践 #

• 保留旧版本静态资源：部署新版本时，不要删除旧的chunk文件，仅上传新生成的文件（由于文件名带唯一哈希，不会产生冲突）。Firebase Hosting支持保留旧文件，可调整部署脚本，跳过旧资源清理步骤，待确认所有用户都切换到新版本后再清理旧文件。
• 使用版本化资源目录：将每个版本的静态资源放到独立的目录下（比如/v1/chunk.abc.js、/v2/chunk.def.js），入口文件指向对应版本的资源目录。这样旧版本的资源会一直保留在专属目录中，不会被新版本覆盖，CDN也能正常缓存各版本的资源文件。
• 精细化配置缓存策略：
  • 给带哈希的chunk文件设置超长缓存过期时间（例如1年），因为文件名唯一，只要内容不变就不会出现缓存失效或错误的问题。
  • 给入口文件index.html设置no-cache或较短的缓存时长（比如5分钟），确保用户能及时获取最新入口，同时避免过于频繁地请求源站。
• 预缓存所有chunk文件：就是你想到的临时方案，可在部署脚本中自动遍历打包生成的所有chunk文件，用curl或爬虫工具批量请求，强制CDN缓存这些文件。这个方法能快速缓解当前问题，但长期来看，结合旧资源保留策略会更稳妥。
• 实现chunk加载失败的优雅处理：在React应用中通过ErrorBoundary捕获chunk加载失败的异常，当检测到加载失败时，提示用户“当前版本已更新，请手动刷新页面”并提供刷新按钮，既避免强制刷新导致的数据丢失，又能引导用户切换到新版本。

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