由于公司的项目越来越多，很多的系统，也有很多相似的模块，为了解决重复造轮子，降低开发维护成本，故将这些抽出来单独作为微应用。经过调研，发现某东出品的micro-app比较吻合。使用过程省略。

在多个项目，同一个域名下 使用同一个微应用是正常的，但是突然某一天，增加了另外一个域名，在同一个浏览器种，先打开A域名，A域名的网站是正常的，然后再打开B域名，B域名引入的微应用就报错了，提示微应用的资源加载出现了跨域问题，如下：

原因

A域名加载了微应用的资源后，浏览器进行了缓存，但是当访问B域名的时候，B域名加载微应用的时候，直接是读取的A域名下的浏览器缓存后的微应用，就会出现条件型 CORS 响应下因缺失 Vary: Origin 导致的缓存错乱问题。

普及2个慨念：

无条件型 CORS 响应

将Access-Control-Allow-Origin固定写死为*（允许任意网站访问）、或者特定的某一个源（只允许这一个网站访问），不论请求头里的 Origin是什么，甚至没有 Origin也一样返回那个值。

条件型 CORS 响应

条件型 CORS 响应又分为两种情况：

1. 区分对待有无 Origin请求头

有Origin请求头才会返回Access-Control-Allow-Origin响应头，没有就不返回。

2. 区分对待不同的 Origin请求头

如果想允许特定的某些个网站访问自己的资源，由于Access-Control-Allow-Origin被设计为不支持返回多个源，这就需要根据 Origin请求头的值来动态的判断出要不要加 Access-Control-Allow-Origin了。

比如我们想只允许 *.baidu.com 下的页面访问，当接受到的请求包含 Origin: https://a.baidu.com时，需要返回 Access-Control-Allow-Origin: https://a.baidu.com；当接受到的请求包含Origin: https://b.baidu.com时，需要返回 Access-Control-Allow-Origin: https://b.baidu.com；当接受到的请求包含 Origin: https://a.baidu.com时，就不返回Access-Control-Allow-Origin头了。

经过分析原因，所以找到处理方案：

解决方案：

在A域名下的 https://a.baidu.com服务端设置：

Access-Control-Allow-Origin: https://a.baidu.com
Vary: Origin

在B域名下的 https://b.baidu.com服务端设置：

Access-Control-Allow-Origin: https://b.baidu.com
Vary: Origin

这样就就可以正常使用了，即使不同的域名使用同一个微应用，各自的域名取各自的缓存，即使是调用同一个域名