相关疑难解决方法(0)

几天前，我已将 Sentry 与我的网站集成，我注意到有时用户会在控制台中收到此错误：

ChunkLoadError: Loading chunk <CHUNK_NAME> failed.
(error: <WEBSITE_PATH>/<CHUNK_NAME>-<CHUNK_HASH>.js)

因此，我调查了网络上的问题，发现了一些类似的情况，但与会话期间发布更新或缓存问题导致的丢失块有关。

这些情况和我的情况之间的主要区别在于，失败的块实际上可以从浏览器访问，因此加载错误并不取决于块哈希值的发布后刷新，而是（我猜）来自一些与网络相关的问题。这一统计数据强化了这一假设：大约 90% 的相关设备都是移动设备。

最后，我提出一个问题：我应该以某种方式管理这个问题（例如，如果失败则重试块加载），还是最好简单地忽略它并让用户手动刷新？

2021年9月28日编辑：

一个月后，问题仍然存在，但我没有收到用户的任何报告，而且我一直在使用 Hotjar 记录用户会话，但到目前为止尚未注意到任何相关内容。

我最近与 Sentry 支持人员进行了一次聊天，帮助我排除了与网络相关的假设：

我们的 React SDK 默认没有离线缓存，当捕获到错误时，它将在此时发送。如果应用程序无法连接到 Sentry 来发送事件，该事件将被丢弃，并且 SDK 不会尝试再次发送该事件。

哨兵鲁道夫

我可以确认这个问题很不寻常，我与您分享另一个有趣的统计数据：自第一次发生以来受影响的用户是332.227 名唯一访问者中的 882 名 (~0,26%)，但我注意到90% 的事件来自 iOS（不是我一个月前注意到的通用移动设备），因此如果我计算 iOS 用户的相同比例（128.444 中的 794 名（882 名中的 90%）），我们接近 0.62%。虽然仍然很小，但在 iOS 上肯定更相关。

这是一个意外的问题,我遇到了Webpack代码在野外分裂:想象一下这种情况:

1. 用户加载带有Webpack代码拆分的React应用程序,并加载一些包块
2. 发生部署,并且更新用户可能从服务器接收的任何未来块的内容(注意:在部署期间,先前的块在服务器上被删除)
3. 用户单击链接并加载新路由,以触发更多捆绑块加载.除了这些新的块与用户的浏览器已经加载的那些不兼容,并且应用程序因运行时错误而中断

如何防止这种情况？

一种可能的解决方案是维护多个版本化的块集,但我想知道大型应用程序是否使用了更简单的解决方案.

如果使用了preload-webpack-plugin,则可以预取所有块,但它们只会在短时间内保持缓存(在Chrome中为5分钟).