本文采取的是“跨域資源共享-Cross Origin Resource Sharing(CORS) 策略”。

一般情況下，前端和後端在兩個專案中，在部署的時候就要部署在兩個域名下，如前端域名：http://www.abc.com/，webAPI域名http://api.abc.com/，這就產生了跨域的問題，跨域的時候會出現這樣的錯誤提示：

“Failed to load http://api.abc.com/api/user: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.abc.com' is therefore not allowed access.”

大概意思就是http://www.abc.com沒有從WebAPI介面http://api.abc.com/獲取資料的許可權，要明確的一點是，這是js上非同步請求的保護機制，不是axios獨有的問題，處理方法這篇部落格有詳細說明：（web api 跨域請求，ajax跨域呼叫webapi）。

我採用的方式是修改WebAPI的webconfig配置，在system.webServer標籤裡邊新增如下配置：

<httpProtocol>
    <customHeaders>
        <add name="Access-Control-Allow-Origin" value="*" />
        <add name="Access-Control-Allow-Headers" value="Content-Type" />
        <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
    </customHeaders>
</httpProtocol>
 

其中value="*"，也可以修改為value="http://www.abc.com"（注意域名後面不帶"/"）；前者是取消所有域名對webapi的訪問限制，後者是指定單個域名有訪問許可權。

這樣處理之後完了嗎？還沒完。。。上的引用的部落格中用一句話簡單的說了下OPTIONS處理的，但是沒說為什麼要處理OPTIONS，而且處理方法是需要對每個控制器修改，這個不太方便。

為什麼會有OPTIONS請求？這是主流瀏覽器跨域請求的機制，在POST請求之前，先發送一個OPTIONS預請求，預請求返回狀態碼正常的情況下才傳送我們真正想要的POST請求，通俗點說，就是POST先找個小弟OPTIONS探探路，小弟說這條路能走，POST才走。這篇文章講的更詳細一點（

提供兩種處理方法：

一、在global中新增上對OPTIONS方法的處理 

protected void Application_BeginRequest()
{
    if (Request.Headers.AllKeys.Contains("Origin") && Request.HttpMethod == "OPTIONS")
    {
        Response.End();
    }
}

二、去掉或註釋掉配置檔案system.webServer標籤中的

<remove name="OPTIONSVerbHandler"/>這個標籤在跨域請求裡邊真是一個大坑（後來求證發現這其實不是坑，允許OPTIONS請求會增加跨站攻擊，服務端風險太大），它應該是表示不接收OPTIONS請求，預請求沒結果，後面的請求是不會執行的。

我驗證的結果是，上面兩種方法，任選一種都可以解決問題。不過我還發現一種情況，在找到上面的解決方案之前，做post請求測試的時候，如果不傳遞引數，服務端不對options請求進行上面的處理也能正常返回，因為瀏覽器的NetWork中顯示，瀏覽器沒有發出options預請求。