最近在项目中遇到一个问题，发送请求时，浏览中显示发送了两个请求，一个是OPTIONS，另一个是实际的请求。然而后台在处理OPTIONS请求的时候，对请求进行了拦截，导致实际请求未能进行。所以需要后台排除下options请求，如下图
1.OPTIONS请求为何会自动发起？
MDN的CORS一文中提到：
规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。
浏览器将CORS请求分为两类：简单请求（simple request）和非简单请求（not-simple-request）,简单请求浏览器不会预检，而非简单请求会预检。这两种方式怎么区分？
2. 跨域请求时，OPTIONS请求触发条件
使用了下面任一HTTP 方法：
PUT/DELETE/CONNECT/OPTIONS/TRACE/PATCH人为设置了以下集合之外首部字段：
Accept/Accept-Language/Content-Language/Content-Type/DPR/Downlink/Save-Data/Viewport-Width/WidthContent-Type 的值不属于下列之一:
application/x-www-form-urlencoded、multipart/form-data、text/plain
3. 优化OPTIONS请求：Access-Control-Max-Age 或者 避免触发
可见一旦达到触发条件，跨域请求便会一直发送2次请求，这样增加的请求数是否可优化呢？答案是可以，OPTIONS预检请求的结果可以被缓存。
Access-Control-Max-Age这个响应首部表示 preflight request （预检请求）的返回结果（即 Access-Control-Allow-Methods 和Access-Control-Allow-Headers 提供的信息） 可以被缓存的最长时间，单位是秒。(MDN)
如果值为 -1，则表示禁用缓存，每一次请求都需要提供预检请求，即用OPTIONS请求进行检测。
评论区的朋友提醒了，尽量避免不要触发OPTIONS请求，上面例子中把content-type改掉是可以的。在其他场景，比如跨域并且业务有自定义请求头的话就很难避免了。现在使用的axios或者superagent等第三方ajax插件，如果出现CORS预检请求，可以看看默认配置或者二次封装是否规范。
参考
https://juejin.cn/post/6844903821634699277
https://segmentfault.com/a/1190000021766588
