兩次請求一般：第一條為options請求，第二條請求才是我們預想中的請求。為什么先發起了一條options請求：
- options請求
options請求的官方定義：OPTIONS方法是用於請求獲得由Request-URI標識的資源在請求/響應的通信過程中可以使用的功能選項。通過這個方法，客戶端可以在采取具體資源請求之前，決定對該資源采取何種必要措施，或者了解服務器的性能。
其實就是：在發生正式的請求之前，先進行一次預檢請求。看服務端返回一些信息，瀏覽器拿到之后，看后台是否允許進行訪問。
如何產生options請求：
產生options請求的原因包括以下幾條：
1：產生了復雜請求。復雜請求對應的就是簡單請求。簡單請求的定義是：
請求方法是GET、HEAD或者POST，並且當請求方法是POST時，Content-Type必須是application/x-www-form-urlencoded, multipart/form-data或着text/plain中的一個值。
請求中沒有自定義HTTP頭部。
所謂的自定義頭部，在實際的項目里，我們經常會遇到需要在header頭部加上一些token或者其他的用戶信息，用來做用戶信息的校驗。
2：發生了跨域。
options請求有什么作用
官方將頭部帶自定義信息的請求方式稱為帶預檢（preflighted）的跨域請求。在實際調用接口之前，會首先發出一個options請求，檢測服務端是否支持真實的請求進行跨域的請求。真實請求在options請求中，通過request-header將 Access-Control-Request-Headers與Access-Control-Request-Method發送給后台，另外瀏覽器會自行加上一個Origin請求地址。服務端在接收到預檢請求后，根據資源權限配置，在response-header頭部加入access-control-allow-headers（允許跨域請求的請求頭）、access-control-allow-methods（允許跨域請求的請求方式）、access-control-allow-origin（允許跨域請求的域）。另外，服務端還可以通過Access-Control-Max-Age來設置一定時間內無須再進行預檢請求，直接用之前的預檢請求的協商結果即可。瀏覽器再根據服務端返回的信息，進行決定是否再進行真實的跨域請求。這個過程對於用戶來說，也是透明的。
另外在HTTP響應頭，凡是瀏覽器請求中攜帶了身份信息，而響應頭中沒有返回Access-Control-Allow-Credentials: true的，瀏覽器都會忽略此次響應。
總結：只要是帶自定義header的跨域請求，在發送真實請求前都會先發送OPTIONS請求，瀏覽器根據OPTIONS請求返回的結果來決定是否繼續發送真實的請求進行跨域資源訪問。所以復雜請求肯定會兩次請求服務端。
options請求如何避免
其實通過以上的分析，我們能得出以下解決方案：
1：使用代理，避開跨域。
2：將復雜跨域請求更改為簡單跨域請求。
3：不使用帶自定義配置的header頭部。