最近客串後端寫個小服務，編程語言爲golang。
前端發送http POST請求後，發現報錯，而後端沒有收到POST請求，反而收到了OPTIONS請求。
經過一番調查發現，當前端發送諸如包含“application/json”的非簡單請求時，會先發送一個OPTIONS請求，此請求稱之爲“預檢請求”。當前端對OPTIONS請求驗證通過後，再發送最終需要發送的http請求。
關於CORS網上介紹非常豐富，不再贅述，佔用篇幅。個人認爲下文寫的非常詳細，僅作參考：
http://www.ruanyifeng.com/blog/2016/04/cors.html
那麼到這裏，情況就明朗了，後端的鍋嘛！響應OPTIONS請求就可以啦。
1. 甄別OPTIONS請求
func (self *ServerHandler) doDealRequest(w http.ResponseWriter, r *http.Request) {
if r.Method == "OPTIONS" {
responseCORS(w)
return
}
// other request
}
2. 響應OPTIONS請求
func responseCORS(w http.ResponseWriter) {
// 自定義類型，僅有下面兩個成員
var resp Response
resp.Description = "ok"
resp.Code = http.StatusOK
w.Header().Set("Access-Control-Allow-Methods", "GET;POST")
// 響應所以域的請求，偷懶，且比較危險
w.Header().Set("Access-Control-Allow-Origin", "*")
// 由於前端的POST請求爲json，所以後端這裏特別註明一下
w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusOK)
jsonStr,_ := json.Marshal(resp)
w.Write(jsonStr)
}
整個過程最重要的是如何響應OPTIONS請求，必須要在response中明確指出：
Access-Control-Allow-Methods
Access-Control-Allow-Origin
Access-Control-Allow-Headers
Content-Type // 這一字段可以省略
當然語言不同，寫法不同，其他語言請自行查找。
3. 打完收工
起名廢，勿噴！