起因
前兩天在做 vue 專案的過程中使用 axios 做介面資料請求，很普通的一個介面，開發的過程中也沒什麼問題。自測的時候鬱悶的發先，每個介面都調了兩次，剛開始沒太注意感覺兩次請求是一摸一樣的，仔細看了一圈，發現第一次呼叫的 Request Method: OPTIONS ，第二次呼叫的 Request Method: POST 。並且 OPTIONS 的請求也損耗了很多的資源。
試想一下，如果每個介面都這樣呼叫兩次，在前端需要多損耗多少資源，這個在複雜專案中的損耗是不可估量的。於是就查了一番資料，看到了很多不同的解決方法，說一下我解決這個問題的方法和問題原因。
解決方案
1. 使用 URLSearchParams
var params = new URLSearchParams()
params.append('param1', 'value1')
params.append('param2', 'value2')
複製程式碼這裡的 params 就是正確請求介面入參，這樣的操作太複雜了，每次都要這樣生成入引數據，實在太累OUT
2. 使用qs.stringify
- 安裝qs
npm install --save qs
複製程式碼
- axios配置
我這裡把 axios 的封裝寫在了 src/plugins/ajax.js
import axios from 'axios'
import qs from 'qs'
// 新增響應攔截器
axios.interceptors.request.use(
config => {
if (config.method === 'post') {
config.data = qs.stringify(config.data)
}
return config
},
error => {
console.log(error)
Promise.reject(error)
}
)
複製程式碼這裡我們看一下，其實就是在 axios 發起請求的前攔截請求，當請求型別是 post 的時候，把請求的入引數據 qs.stringify 一下，看一下前後資料格式的對比。
// qs.stringify 前
{
"userId": "520b0ec329164dd9a4f216ba8d209029",
"startTime": "1548950400000",
"endTime": "1551369599999"
}
// qs.stringify 後
"userId=520b0ec329164dd9a4f216ba8d209029&startTime=1548950400000&endTime=1551369599999"
複製程式碼這時候再去看後臺我發起的請求，OPTIONS 已經不存在啦，只發起了一次正常的 post 請求
但是遺憾的是，雖然介面請求型別正確了，但是介面返回的資料錯了，介面提示沒有獲取到正確的入引數據，跟後端的同學一起看了下，應該是入參的資料型別從
json變成的string，後端無法正確獲取到，這裡就需要後端的同學獲取入參格式化一下獲取到的資料。這樣一切就搞定了。
3. 使用Access-Control-Max-Age
這裡說一個最簡單的解決方法，只要後端同學在設定跨域請求資料的時候，新增 Access-Control-Max-Age ，這個引數的意思是把 OPTIONS 快取起來，在指定的時間內，不會再次發起 OPTIONS 預請求，這樣只有在第一次請求的時候會有 OPTIONS ，如果這個時間拉的足夠長，其實並不太損耗資源，這算是一個迂迴解決的方法。
// 後端設定，2592000單位秒，這裡是30天
response.addHeader( "Access-Control-Max-Age", "2592000" )
複製程式碼在控制檯開啟 Disable cache，可以看到請求中還有 OPTIONS ，關閉 Disable cache 之後，再看請求已經沒有了 OPTIONS
以上就是我們在 axios 中如果遇到複雜請求 OPTIONS 時候的幾種解決辦法，請各位多指教。
