使用延迟加载/代码拆分处理“加载块失败”错误答案

【问题标题】：Handle "Loading chunk failed" errors with Lazy-loading/Code-splitting使用延迟加载/代码拆分处理“加载块失败”错误
【发布时间】：2019-07-20 05:53:00
【问题描述】：

我们正在开发一个基于 Vue CLI 3 与 Vue Router 和 Webpack 的 Vue.js 应用程序。 routes are lazy-loaded 和 chunk file names contain a hash 用于缓存清除。总的来说，一切正常。

但是，在部署过程中出现了问题。重现步骤如下。

用户打开应用程序（假设路由“/”），因此主块文件被加载。
我们更改了应用程序中的某些内容并部署了新版本。
- 旧的块文件被删除
- 正在添加新的块文件（即块文件名中的哈希值更改）
用户单击指向另一条路由的链接（例如“/foo”）
- 应用程序尝试加载已重命名的块文件时发生错误：Error: "Loading CSS chunk foo failed. (/assets/css/foo.abc123.css)"（可能是 CSS 或 JavaScript）

避免此类错误的最佳方法是什么？

一种可行的方法是保留旧的块文件并在以后删除它们。但是，这会使新版本的部署变得复杂，因为您需要跟踪旧版本并始终使用新版本部署旧块文件。
另一种（天真的）方法是在检测到此类错误后立即重新加载（例如Vue Lazy Routes & loading chunk failed）。它有点工作，但它重新加载 old 路线，而不是 new 路线。但至少它可以确保连续的路线更改再次起作用。

还有其他想法吗？也许 webpack 中有一些东西可以解决这个问题？

【问题讨论】：

热重载（webpack）不应该完全按照你的要求做吗？
@bigless 在开发期间是的，但不是在生产中。
动态哈希链接也就是生产中的块不是一个好主意。它应该是查询参数或锚点的形式，但不是抛出 404.. 的链接
@bigless 文件名中的哈希显然有问题，但据我所知是行业标准（例如Google recommends it）。查询参数在几年前效果不佳（例如，由于代理），但它们今天可能有效。我找不到明确的资源。但是锚点肯定是行不通的。
我们多年来一直在生产环境中使用查询版本控制并且它有效。我们在包构建时将版本（f.e. ?v=1.66.5）生成到模板中，并像页面上每个本地资源的后缀一样包含它。

【解决方案1】：

只要您有版本化的 API，您就可以使用旧的应用程序文件（只需将它们留在服务器上并在几天后删除）。

一旦您的 API 在部署期间发生更改，您就会遇到问题。

我假设，您每次部署新的 JS 代码时都会部署一个新的 API。

那么你可以：

对于异步组件，如果加载失败，我们会显示正常的“未找到”消息，并显示一个重新加载按钮而不是组件。在没有用户交互的情况下重新加载会导致很多混乱。

【讨论】：

【解决方案2】：

不要缓存入口文件（通常是 index.html）。我们添加：

expires 0;
add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate';

在我们的 nginx 服务器配置中。

然后，在你刷新客户端的代码之后，你就可以使用 vue-router 的错误钩子来检测错误并正确地做一些事情了。

【讨论】：