这不是一个通用的缓存方案，但是分享给大家希望有所帮助～

为什么是微前端

一般来说，缓存的目的是降低重复请求的成本

对于普通应用来说，重复请求一般是第二次访问（刷新页面）才会产生。一般情况下，我们使用http的缓存方案即可

但是对于微前端而言，在第一次使用的时候就会加载多个子应用，每个子应用都会加载自己的资源。哪怕这些资源有相同的也没办法命中http缓存

所以在微前端架构下，如何高效利用多个应用下的相同资源才是重点

微前端现状

当前微前端架构大多是一个基座+多个子应用的模式。一般情况下基座有以下几方面的能力：

那么，如何重新利用多个独立的子应用的公共部分呢？

比如基座提供 react、lodash、antd等标准库

但是这个方案有比较强的应用限制：即子应用的技术栈一致。

同时带来另一个问题：版本无法精细化管控。每个子应用都必须使用相同的版本

即通过合理的配置打包工具，让公共模块，三方lib单独成chunk。使用内容hash作为chunkName。平台提供统一的缓存策略，只要hash一致则认为可以复用

也解决了版本的问题

最终我使用了hash的方案来做缓存。再不侵入业务代码的前提下，做了一套通用的方案

利用Service Worker 拦截请求，检查文件hash，存在相同直接返回。存在不同则缓存到本地

在不支持Service worker的环境对 xhr、appendChild 做劫持从而达到相同目的