經過本人的最後測試得出的結論是
由于最近做的項目中有一部分是接口遠端調用，用到了接入權限和業務權限的鑒定，需要采用springmvc的攔截器，以前用struts2的時候用過攔截器，而springmvc的攔截器功能之前沒研究過，是以這次來稍微研究一下，得出的結論是springmvc的攔截器和struts2的攔截器原理幾乎是一模一樣的，都是利用反射功能實作動态代理。
因為過濾器和攔截器有很多相似甚至相同的地方，因為很多時候二者都能達到相同的能力。是以也重新看了下過濾器。
過濾器和攔截器的差別，百度了一下：
①攔截器是基于java的反射機制的，而過濾器是基于函數回調。
②攔截器不依賴與servlet容器，過濾器依賴與servlet容器。
③攔截器隻能對action請求起作用，而過濾器則可以對幾乎所有的請求起作用。
④攔截器可以通路action上下文、值棧裡的對象，而過濾器不能通路。
⑤在action的生命周期中，攔截器可以多次被調用，而過濾器隻能在容器初始化時被調用一次
filter
寫了點測試代碼，順便整理一下思路，搞清楚這幾者之間的順序：
1.過濾器是javaee标準，采用函數回調的方式進行。是在請求進入容器之後，還未進入servlet之前進行預處理，并且在請求結束傳回給前端這之間進行後期處理。
chain.dofilter(request, response);這個方法的調用作為分水嶺。事實上調用servlet的doservice()方法是在chain.dofilter(request, response);這個方法中進行的。
2.攔截器是被包裹在過濾器之中的。
a.prehandle()這個方法是在過濾器的chain.dofilter(request, response)方法的前一步執行，也就是在 [system.out.println("before...")][chain.dofilter(request, response)]之間執行。
b.prehandle()方法之後，在return modelandview之前進行，可以操控controller的modelandview内容。
c.aftercompletion()方法是在過濾器傳回給前端前一步執行，也就是在[chain.dofilter(request, response)][system.out.println("after...")]之間執行。
3.springmvc的機制是由同一個servlet來分發請求給不同的controller，其實這一步是在servlet的service()方法中執行的。是以過濾器、攔截器、service()方法，dispatc()方法的執行順序應該是這樣的，大緻畫了個圖：其實非常好測試，自己寫一個過濾器，一個攔截器，然後在這些方法中都加個斷點，一路f8下去就得出了結論。
總結：攔截器功在對請求權限鑒定方面确實很有用處，在我所參與的這個項目之中，第三方的遠端調用每個請求都需要參與鑒定，是以這樣做非常友善，而且他是很獨立的邏輯，這樣做讓業務邏輯代碼很幹淨。和架構的其他功能一樣，原理很簡單，使用起來也很簡單，大緻看了下springmvc這一部分的源碼，其實還是比較容易了解的。
我們項目中僅僅用到了prehandle這個方法，而未用其他的，架構提供了一個已經實作了攔截器接口的擴充卡類handlerinterceptoradapter，繼承這個類然後重寫一下需要用到的方法就行了，可以少幾行代碼，這種方式java中很多地方都有展現。