因此，我的公司正在为我们的应用程序使用微前端架构。这是我一直在这里开展的一个项目，到目前为止，它已经相当成功。但是，我希望就我们面临的挑战之一获得一些建议。
当您使用Webpack构建JavaScript应用程序时，一种选择是将哈希添加到URL。该哈希值是在每次构建时生成的，因此哈希值仅在文件本身发生更改时才会更改。所以文件名看起来像这样：
app.ab12cd.js
这样做的优点是浏览器缓存。浏览器将尝试缓存内容，以避免不得不消耗过多的数据。因此，如果再次看到相同的文件名/ URL，它将仅使用缓存的版本，而不是重新下载它。由于文件名中的哈希值只有在更改后重新生成文件时才会更改，因此我们可以安全地依靠浏览器将该文件缓存起来，以减轻用户的无线下载负担，同时仍然确信他们会始终查看最新更改。
这是我们的微前端架构所面临的挑战。指导原则之一是每个微前端都可以单独发布，这意味着基本应用程序（即用户导航到的初始应用程序）与将要加载的微前端应用程序之间没有直接依赖关系。 >
我们通过简单的静态标签来完成此操作。每次我们添加一个新的微前端时，我们只需更新一次基本应用程序即可添加一个新标签：
<script src="micro-frontend/assets/js/app.js"></script>在上面的示例中，使用nginx代理将该URL重定向到了实际部署的微前端。由于涉及我们公司基础架构的愚蠢和令人沮丧的原因，它是一个相对URL，但这是另一个切线。
要点是，您会注意到它指向的是“ app.js”，而不是“ app.12ab34.js”。我们不使用哈希，因为我们不想每次微前端更改时都更新基本应用程序。相反，我们将返回Cache-Control标头，以防止浏览器缓存微前端。
这也不是理想的，因为当我们获得独立性时，我们会释放微前端代码的缓存。
因此，我的问题：如果我们要在微前端的文件名中启用哈希，是否可以在无需更改哈希值的情况下就可以设置基本应用程序？换句话说，连接我尚未想到的这些应用程序是否有完全不同的方式？
非常感谢。
因此，我的公司正在为我们的应用程序使用微前端架构。这是我一直在这里开展的一个项目，到目前为止，它已经相当成功。但是，我希望得到一些...
您正在混合考虑-缓存清除并获得软件包的特定version