写在前面
由于这篇博客承接自我的上一篇博客，因此在看这篇博客之前先看我的上一篇博客哦～
问题的由来
前几天我写了篇记录前端实现跨域的操作并成功实现了跨域（通过代理为响应头添加允许跨域的字段），今天突然发现不work了，又报了跨域的错误，报错信息如下：
在Crome中查看预检请求
关于简单请求、复杂请求，以及预检请求（OPTIONS）的由来网上有很多介绍性的文章，在此不再赘述。一言以蔽之，是因为我们获取token的post请求设置了content-type: application/json的头部字段引起了浏览器的预检请求。
默认情况下在crome的开发者工具是不能查看预检请求的，要想查看该请求，网上有一些过时的解决方案（通过浏览器设置禁用某字段，现在是找不到该字段的）。关于浏览器的同源策略、安全机制crome的更新速度是很快的，低版本的解决方案往往不适用于90+新版本的crome。在最新版本的crome中查看预检请求的方法简单了很多，如下图所示，在Other选项卡下就能查看到预检请求，是不是很简单？😃
通过代理修改预检请求的状态码
通过报错信息我们知道对于该预检请求浏览器希望能够拿到一个ok的http状态码，现在服务端对于该请求返回了405，导致浏览器没有继续发送获取token的post请求。因此我们接下来的目标是通过代理修改服务端对于预检请求的状态码，那么具体怎么做呢？下面直接给出答案：
即在之前添加响应头的后面加上replaceStatus://200，表示代理服务器将服务端返回的http状态码替换为200。这里有一个坑是千万不要写成statusCode://200，因为这表示代理服务器将拦截该请求并作为服务端向你的客户端返回200，并没有向服务端发送请求！
我们来看下现在的表现：
可以看到先前的错误已经被解决了，但是报了新的跨域的错误。
为预检请求添加响应头
从报错信息不难看出，是因为我们在预检请求之后发送了带有content-type头部字段的post请求，而该字段没有出现在预检请求的Access-Control-Allow-Headers响应头中。解决方法比较简单，类似于上一篇博客的操作，首先构造一个包含该字段的响应头（在原来的基础上增加了最后一项配置）：
并在rules中应用该配置：
处理其它预检请求
经过上述操作我们已经完成了第一个请求并获取到了token，我们发现第二个获取文章内容的get请求同样存在预检行为，产生预检请求的原因是该get请求的头部字段中含有对CORS安全的头部字段集合之外的字段。我们如法炮制：
即也更改其预检请求的状态码为200。
现在的表现？
有了前面的经验这里就很容易了，添加该响应的头部字段：
到现在，我们的文章又能正确的显示出来啦！
补充内容：
预检请求产生的条件：
