今天做專案，前端的大佬用axios傳送post請求，而我要利用過濾器和攔截器進行許可權的校驗，校驗的內容就是上送的某個欄位的內容，所以我們需要重寫request請求（request請求只能獲取一次，如果在攔截器中獲取，那麼控制器就獲取不到相應的引數），並且在攔截器中進行校驗，我先重寫HttpServletWrapper，然後獲取流，進行操作，但是我獲取到的流資料都是null，但是用postman測試，卻可以獲取到。出現問題我先將每一次經過攔截器和過濾器的請求打印出來。發現每一次post請求，前端都會請求兩次我的藉口，但是第一次inputStream是null，第二次有我想要的引數，經過網上百度，我發現：

因為vue-resource不在更新，vue推薦使用axios，所以使用axios。 在頁面互動過程中，發現axios一定機率會發送兩次請求，一次是自己設定的請求方式，還有一次是options。 關於這個問題，在各個網站尋求原因，得出以下結論： 跨域資源共享標準新增了一組 HTTP 首部欄位，允許伺服器宣告哪些源站有許可權訪問哪些資源。另外，規範要求，對那些可能對伺服器資料產生副作用的 HTTP 請求方法（特別是 GET 以外的 HTTP 請求，或者搭配某些 MIME 型別的 POST 請求），瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知服務端是否允許該跨域請求。伺服器確認允許之後，才發起實際的 HTTP 請求。在預檢請求的返回中，伺服器端也可以通知客戶端，是否需要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關資料）。 也就是說，它會先使用options去測試，你這個介面是否能夠正常通訊，如果不能就不會發送真正的請求過來，如果測試通訊正常，則開始正常請求。

知道問題出現在哪裡，那麼我就有解決的辦法啦，因為只是options請求：OPTIONS方法是用於請求獲得由Request-URI標識的資源在請求/響應的通訊過程中可以使用的功能選項。通過這個方法，客戶端可以在採取具體資源請求之前，決定對該資源採取何種必要措施，或者瞭解伺服器的效能.該請求方法的響應不能快取。reflighted Requests是CORS中一種透明伺服器驗證機制。預檢請求首先需要向另外一個域名的資源傳送一個 HTTP OPTIONS 請求頭，其目的就是為了判斷實際傳送的請求是否是安全的。

那麼這種機制跟我想要使用的攔截器有一些衝突，因為OPTIONS請求沒有引數。那麼當時RequestMethod是OPTIONS時我們不應該做任何操作，直接通過，但是攔截器又是根絕訪問地址URL來判斷的，那麼我們就在攔截器剛剛進去就通過OPTIONS請求，即：“OPTIONS”.equals(request.getMethod())  return true;通過攔截器