前言

跨域这两个字就像一块狗皮膏药一样黏在每一个前端开发者身上，无论你在工作上或者面试中无可避免会遇到这个问题。如果在网上搜索跨域问题，会出现许许多多方案，这些方案有好有坏，但是对于阐述跨域的原理和在什么情况下需要用什么方案，缺少系统性的说明。大家在工作中可能因为大佬们已经配置好了，不会产生跨域，但是作为一个前端的开发人员，面对跨域的问题，还是需要从原理上去理解跨域的原因，在不同的情况中，我们该如何去处理。

1 业务场景

1.1 介绍

WMS6.0是一款专门为仓储业务打造的合作开发平台，前台BP可以独立开发或者定制现有的流程，接入到WMS6.0中，实现自定义业务，使前台BP只需要关注自己的业务，不用专注其他功能，提升前台BP的开发效率。。

作为一个合作平台，WMS6.0 PC端支持独立页面扩展和页面内部功能扩展，支持前台BP可以进行独立部署，实现最大程度的解耦。接入方案如下：

• 独立页面扩展，以完全独立业务模块的方式接入。针对部分合作方需要自己完全独立开发页面的情况，WMS6.0提供了微前端的框架进行接入。
• 页面内部功能扩展，以预留插槽的方式接入。如图1中标注部分所示，整体页面被划分为多个区域，其中包含了通用的数据模块 + bp接入模块。当合作方有个性化的数据统计需求时，可以进行独立开发，然后接入现有公用页面中。

在bp接入平台的过程中，我们遇到了各种各样的问题，如前后端如何联调、如何在不冲突的情况下自定义全局属性、如何部署上线等等，下面我们主要就前后端联调中遇到的跨域问题进行讨论。

在使用上述预留插槽的接入方式时，为了通用模块与接入模块之间的数据同步等方便进行，WMS6.0中并没有使用老式的iframe，而是采用了vue注册的方式，实现在同一个页面中加载。因此合作方在独立模块中发起的服务端请求，其来源其实仍是当前通用页面。

而WMS6.0并不能确保所有的合作方服务端均在同一个域名下，由此也就产生了各种交互问题。

1.2 wms6.0请求链路

我们先来看一下WMS6.0现有的通用网络请求整体链路。

当用户触发了网络请求，会通过基站或者仓库的路由发出，然后通过网络到达物流网关，物流网关把请求转发到Nginx，Nginx会把请求分发到具体的服务器上进行数据处理。

下面我们就抽取一个WMS6.0通过物流网关访问的请求，作为实例来看一下。

通过response Headers（相应头）我们可以看到，公司现有的物流网关会对指定域名的页面进行CORS跨域处理。通过Access-Control-Allow-Origin: http://a..com，我们可以知道物流网关可以接受来自指定域 http://a..com 的跨域资源请求，不会产生跨域报错。

但是咱们部分bp合作方的接口并不是通过物流网关的，这就需要我们自己对此类接口进行跨域处理了。假如没有进行跨域处理，那么就会报下面的错了。

1.3 跨域的产生

• Access to XMLHttpRequest at '' from origin '' has been blocked by CORS policy
• Response to preflight request doesn't pass access control check
• No 'Access-Control-Allow-Origin' header is present on the requested resource.

报错解析：

从源“本地路径”访问 “目标路径(请求链接)”的文本传输请求已被CORS策略阻塞：对预检请求的响应未通过访问控制检查。请求的资源上不存在'Access- control - allow - origin '报头。

错误原因：

本地路径和目标路径不在同一个域名下引起的跨域问题。

同时需要注意的是，就算两个域名是同一个二级域名、不同三级域名的时候，例如 a.baidu.com 和 b.baidu.com ，也是属于不同域的，仍会出现这个问题。

那么到底什么是跨域，跨域既然影响了我们的开发工作，那又为什么要有对跨域的限制呢？下面让我们来了解一下跨域的历史产生原因和作用吧。

2 跨域

2.1 演变史

以下内容为个人猜测，仅供参考，勿喷