是因為204是http的options請求方式，判斷請求是否成功，返回200的才是你的真實請求。

跟 axios 沒關系，那個返回 204 的是 options 請求，跟 CORS 的跨域支持請求有關。
（以下引用自：CSDN 博客 - 柳下聽雨）

我們公司的項目都是前后端分離的，上線幾個月以來，發(fā)現(xiàn)一個很奇怪的問題，每次前端發(fā)起請求，通過瀏覽器的開發(fā)者工具都能看到在Network下同一個url有兩條請求，第一條請求的Method為OPTIONS，第二條請求的Method才是真正的GET或者POST，并且，第一條請求無數(shù)據(jù)返回，第二條請求才會返回正常的數(shù)據(jù)。

發(fā)現(xiàn)這個問題之后，立即組織搜索問題產生的原因以及解決方案。在網(wǎng)上搜索了大量資料，得到的一個結論是：第一個OPTIONS的請求是由Web服務器處理跨域訪問引發(fā)的。網(wǎng)上資料顯示，OPTIONS是一種“預檢請求”，瀏覽器在處理跨域訪問的請求時如果判斷請求為復雜請求，則會先向服務器發(fā)送一條預檢請求，根據(jù)服務器返回的內容瀏覽器判斷服務器是否允許該請求訪問。如果web服務器采用cors的方式支持跨域訪問，在處理復雜請求時這個預檢請求是不可避免的。

查詢代碼發(fā)現(xiàn)，我們的web服務器確實采用的是cors來解決跨域訪問的問題，并且我們在header中添加了自定義參數(shù)，導致我們的每次請求都為復雜請求，從而產生了每次請求都會發(fā)送兩條請求的現(xiàn)象。

問題的原因找到了，就要想辦法解決這個問題。既然瀏覽器在處理復雜請求時，不可避免的要發(fā)送預檢請求，那么能否減少預檢請求的次數(shù)呢？比如，預檢一次設置一個有效期，在有效期內不再重復預檢。順著這個思路，繼續(xù)搜索相關資料，最終發(fā)現(xiàn)設置Access-Control-Max-Age這個參數(shù)即可達到預期目標。該參數(shù)用來指定本次預檢請求的有效期，單位為秒。在服務器上設置該參數(shù)之后，問題解決了，大快人心?。?！

參考資料：http://blog.csdn.net/charlesl...