浏览器同源策略
浏览器安全的基石是同源策略。1995年，同源政策由 Netscape 公司引入浏览器。目前，所有浏览器都实行这个政策。最初，它的含义是指，A网页设置的 Cookie，B网页不能打开，除非这两个网页"同源"。
同源
- 协议相同
- 域名相同
- 端口相同
目的
同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。如果Cookie 可以共享，互联网就毫无安全可言了。
限制范围
随着互联网的发展，"同源政策"越来越严格。目前，如果非同源，共有三种行为受到限制。
- Cookie、LocalStorage 和 IndexDB 无法读取
- DOM 无法获得
- AJAX 请求不能发送
com
baidu.com
虽然这些限制是必要的，但是有时很不方便，合理的用途也受到影响。上面的限制也都有手段进行规避，比如对于Cookie，如果两个网页一级域名相同，只是二级域名不同，浏览器允许通过设置document.domain共享 Cookie：
A网页是http://w1.example.com/a.html，B网页是http://w2.example.com/b.html，那么只要设置相同的document.domain，两个网页就可以共享Cookie。
document.domain = 'example.com';
A网页通过脚本设置一个 Cookie:
document.cookie = "test1=hello"
B网页就可以读到这个 Cookie：
var allCookie = document.cookie;
其他的规避：
LocalStorage和IndexDB可以通过window.postMessage- DOM（典型的例子是
iframe窗口和window.open方法打开的窗口，它们与父窗口无法通信）可以通过片段识别符、window.name、window.postMessage（HTML5的全新API） AJAX请求可以通过JSONP（兼容性好，只支持GET，基本思想是，网页添加script元素）、WebSocket、CORS（Cross-Origin Resource Sharing，跨源资源分享。根本解决方法）
什么是跨域
非同源，就会跨域。跨域是指一个域下的文档或脚本试图去请求另一个域下的资源，这里跨域是广义的。
广义的跨域：
- 资源跳转： A链接、重定向、表单提交
- 资源嵌入： 、
- 脚本请求： js发起的ajax请求、dom和js对象的跨域操作等
我们通常所说的跨域是狭义的，是由浏览器同源策略限制的一类请求场景。
CORS
CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。
整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。
因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。
浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。
简单请求
定义
同时满足以下两大条件，就属于简单请求：
（1) 请求方法是以下三种方法之一：
- HEAD
- GET
- POST
（2）HTTP的头信息不超出以下几种字段：
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type：只限于三个值
application/x-www-form-urlencoded、multipart/form-data、text/plain
基本流程
对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段，表示本次请求来自哪个源（协议 + 域名 + 端口），服务器根据这个值，决定是否同意这次请求。
如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。
（1）Access-Control-Allow-Origin
该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。
（2）Access-Control-Allow-Credentials
该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。
（3）Access-Control-Expose-Headers
该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。
非简单请求
定义
不满足简单请求定义的请求，就是非简单请求。
预检请求
非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。
除了Origin字段，"预检"请求的头信息包括两个特殊字段。
（1）Access-Control-Request-Method
该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。
（2）Access-Control-Request-Headers
该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。
一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。
如何取消预检请求
- 发出简单请求。【最终方案】
- 服务器端设置
Access-Control-Max-Age字段，那么当第一次请求该URL时会发出 OPTIONS 请求，浏览器会根据返回的Access-Control-Max-Age字段缓存该请求的OPTIONS预检请求的响应结果（具体缓存时间还取决于浏览器的支持的默认最大值，取两者最小值，一般为 10分钟）。在缓存有效期内，该资源的请求（URL和header字段都相同的情况下）不会再触发预检。（chrome 打开控制台可以看到，当服务器响应Access-Control-Max-Age时只有第一次请求会有预检，后面不会了。注意要开启缓存，去掉 disable cache 勾选。）
但是， Access-Control-Max-Age的缓存时间是有上限的，火狐是24小时，Chrome在v76之前是10分钟，v76开始是2小时，默认值是5秒。如果值为 -1，表示禁用缓存，则每次请求前都需要使用 OPTIONS 预检请求。详见MDN。
axios 使用 post 发送数据时，默认是直接把 json 放到请求体中提交到后端的。也就是说，我们的 Content-Type 变成了 application/json;charset=utf-8 ,这是axios默认的请求头content-type类型。
post请求常见的数据格式（content-type）：
- Content-Type: application/json ： 请求体中的数据会以json字符串的形式发送到后端
- Content-Type: application/x-www-form-urlencoded：请求体中的数据会以普通表单形式（键值对）发送到后端（比如可以用
Qs.stringify或者URLSearchParams） - Content-Type: multipart/form-data： 它会将请求体的数据处理为一条消息，以标签为单元，用分隔符分开。既可以上传键值对，也可以上传文件
代理
同源策略是浏览器的安全策略，不是HTTP协议的一部分。服务器端调用HTTP接口只是使用HTTP协议，不会执行JS脚本，不需要同源策略，也就不存在跨越问题。
