過濾器
- filter接口中定義了三個方法
- init():Filter的整個生命週期被調用一次
- destroy():Filter的整個生命週期被調用一次
- dofilter():容器的每一次請求都調用該方法,FilterChain用來調用下一個過濾器Filter
攔截器
- 攔截器是鏈式調用,一個應用中可以同時存在多個攔截器Interceptor， 一個請求也可以觸發多個攔截器 ，而每個攔截器的調用會依據它的聲明順序依次執行。
- 攔截器也定義了三個方法:
- preHandle:這個方法在請求處理前調用
- postHandle:在preHandle返回值爲true時才執行
- afterCompletion:只有在 preHandle() 方法返回值爲true 時纔會執行。在整個請求結束之後， DispatcherServlet 渲染了對應的視圖之後執行.
不同之處
實現原理不同
過濾器 是基於函數回調的，攔截器 則是基於Java的反射機制（動態代理）實現的。
使用範圍不同
- 我們看到過濾器 實現的是 javax.servlet.Filter 接口，而這個接口是在Servlet規範中定義的，也就是說過濾器Filter 的使用要依賴於Tomcat等容器，導致它只能在web程序中使用。
- 而攔截器(Interceptor) 它是一個Spring組件，並由Spring容器管理，並不依賴Tomcat等容器，是可以單獨使用的。不僅能應用在web程序中，也可以用於Application、Swing等程序中。
觸發時機不同
- 過濾器Filter是在請求進入容器後，但在進入servlet之前進行預處理，請求結束是在servlet處理完以後。
- 攔截器 Interceptor 是在請求進入servlet後，在進入Controller之前進行預處理的，Controller 中渲染了對應的視圖之後請求結束。
攔截的請求範圍不同
過濾器幾乎可以對所有進入容器的請求起作用，而攔截器只會對Controller中請求或訪問static目錄下的資源請求起作用。
注入bean情況不同
- 過濾器正常注入
- 但是攔截器報異常,注入的是null,這是因爲攔截器加載的時間點在springcontext之前，而Bean又是由spring進行管理。
------ 解決方案也很簡單，我們在註冊攔截器之前，先將Interceptor 手動進行注入。「注意」：在registry.addInterceptor()註冊的是getMyInterceptor() 實例。
控制執行順序不同
- 過濾器用@Order註解控制執行順序，通過@Order控制過濾器的級別，值越小級別越高越先執行。
- 攔截器默認的執行順序，就是它的註冊順序，也可以通過Order手動設置控制，值越小越先執行。
- 要知道controller 中所有的請求都要經過核心組件DispatcherServlet路由，都會執行它的 doDispatch() 方法，而攔截器postHandle()、preHandle()方法便是在其中調用的。