今天學(xué)習(xí)和認(rèn)識了一下，過濾器和SPRingMVC的攔截器的區(qū)別，學(xué)到了不少的東西，以前一直以為攔截器就是過濾器實現(xiàn)的，現(xiàn)在想想還真是一種錯誤啊，而且看的比較粗淺，沒有一個全局而又細(xì)致的認(rèn)識，由于已至深夜，時間原因，我就把一些網(wǎng)友的觀點重點摘錄下來，大家仔細(xì)看后也一定會有一個比較新的認(rèn)識（在此非常感謝那些大牛們的無私奉獻，分享他們的經(jīng)驗與心得，才能讓像我這樣的小白有機會站一下你們這些巨人的肩膀，才能少走些彎路）。

　　過濾器和攔截器的區(qū)別：

　?、贁r截器是基于java的反射機制的，而過濾器是基于函數(shù)回調(diào)。 　?、跀r截器不依賴與servlet容器，過濾器依賴與servlet容器。 　?、蹟r截器只能對action請求起作用，而過濾器則可以對幾乎所有的請求起作用。 　　④攔截器可以訪問action上下文、值棧里的對象，而過濾器不能訪問。 　?、菰赼ction的生命周期中，攔截器可以多次被調(diào)用，而過濾器只能在容器初始化時被調(diào)用一次。

　?、迶r截器可以獲取IOC容器中的各個bean，而過濾器就不行，這點很重要，在攔截器里注入一個service，可以調(diào)用業(yè)務(wù)邏輯。

　　寫了點測試代碼，順便整理一下思路，搞清楚這幾者之間的順序：

　　1.過濾器是JavaEE標(biāo)準(zhǔn)，采用函數(shù)回調(diào)的方式進行。是在請求進入容器之后，還未進入Servlet之前進行預(yù)處理，并且在請求結(jié)束返回給前端這之間進行后期處理。

　　chain.doFilter(request, response);這個方法的調(diào)用作為分水嶺。事實上調(diào)用Servlet的doService()方法是在chain.doFilter(request, response);這個方法中進行的。

　　2.攔截器是被包裹在過濾器之中的。

　　a.preHandle()這個方法是在過濾器的chain.doFilter(request, response)方法的前一步執(zhí)行，也就是在 [System.out.println(“before…”)][chain.doFilter(request, response)]之間執(zhí)行。

　　b.preHandle()方法之后，在return ModelAndView之前進行，可以操控Controller的ModelAndView內(nèi)容。

　　c.afterCompletion()方法是在過濾器返回給前端前一步執(zhí)行，也就是在[chain.doFilter(request, response)][System.out.println(“after…”)]之間執(zhí)行。

　　3.SpringMVC的機制是由同一個Servlet來分發(fā)請求給不同的Controller，其實這一步是在Servlet的service()方法中執(zhí)行的。所以過濾器、攔截器、service()方法，dispatc()方法的執(zhí)行順序應(yīng)該是這樣的，大致畫了個圖：其實非常好測試，自己寫一個過濾器，一個攔截器，然后在這些方法中都加個斷點，一路F8下去就得出了結(jié)論。

　　總結(jié)：攔截器功在對請求權(quán)限鑒定方面確實很有用處，在我所參與的這個項目之中，第三方的遠(yuǎn)程調(diào)用每個請求都需要參與鑒定，所以這樣做非常方便，而且他是很獨立的邏輯，這樣做讓業(yè)務(wù)邏輯代碼很干凈。和框架的其他功能一樣，原理很簡單，使用起來也很簡單，大致看了下SpringMVC這一部分的源碼，其實還是比較容易理解的。

　　我們項目中僅僅用到了preHandle這個方法，而未用其他的，框架提供了一個已經(jīng)實現(xiàn)了攔截器接口的適配器類HandlerInterceptorAdapter，繼承這個類然后重寫一下需要用到的方法就行了，可以少幾行代碼，這種方式Java中很多地方都有體現(xiàn)。

以上部分是摘自神一樣存在的博客，參考了一下這個帖子：http://haohaoxuexi.iteye.com/blog/1750680

大家還可以參考一下這個電子書的截圖：