在現代Web應用開發中，尤其是在Java生態系統中，我們經常會遇到「攔截器（Interceptor）」和「過濾器（Filter）」這兩個概念。它們都用於在請求到達核心業務邏輯之前或之後執行某些操作，但它們在設計思想、作用層次、適用場景及可訪問的上下文信息方面存在顯著差異。理解攔截器和過濾器的區別對於構建高效、健壯且易於維護的應用程序至關重要。
過濾器（Filter）深度解析
什麼是過濾器（Filter）？
過濾器（Filter）是基於Servlet規範的Web組件，它在客戶端的請求到達Servlet之前，或在Servlet的響應發送回客戶端之前，對請求和響應進行預處理和后處理。簡而言之，過濾器是一個位於Web應用程序前端的「守門員」，負責攔截所有進入Web容器的請求和離開Web容器的響應。
它的核心作用在於：
- 對用戶請求進行預處理，例如字元編碼統一、參數校驗、身份驗證、日誌記錄等。
- 對伺服器響應進行后處理，例如數據壓縮、敏感信息過濾等。
過濾器的工作原理
過濾器鏈（Filter Chain）是其核心機制。當一個請求到達Web伺服器時，如果該請求需要經過多個過濾器的處理，這些過濾器會按照它們在web.xml或通過註解配置的順序形成一個鏈。每個過濾器在執行完自己的邏輯后，可以選擇將請求傳遞給鏈中的下一個組件（下一個過濾器或目標Servlet），也可以直接終止請求的進一步處理。
主要方法：
init(FilterConfig filterConfig)：過濾器初始化時調用。doFilter(ServletRequest request, ServletResponse response, FilterChain chain)：每次請求到達時調用，是實現過濾邏輯的核心方法。destroy()：過濾器銷毀時調用。
常見應用場景：
- 字元編碼統一： 確保所有請求的字元編碼正確，避免亂碼。
- 身份驗證與許可權校驗： 攔截未登錄或無許可權的請求，強制重定向到登錄頁面或返回錯誤信息。
- 日誌記錄： 記錄所有請求的訪問信息（如IP地址、訪問時間、URL等）。
- 數據壓縮： 對響應數據進行GZIP壓縮，減少網路傳輸量。
- XSS/SQL注入防護： 過濾用戶輸入，防止惡意腳本或SQL注入攻擊。
- 請求與響應頭的修改： 添加或修改HTTP頭部信息。
過濾器的特點
- 基於Servlet容器： 它是Servlet規範的一部分，與具體的Web框架（如Spring MVC、Struts2）無關，只要是支持Servlet規範的容器（如Tomcat、Jetty）都可以使用。
- 獨立於框架： 它可以應用於任何基於Servlet的Web應用程序，無需依賴特定的MVC框架。
- 作用於請求生命周期： 過濾器在請求進入Web容器的最前端進行攔截，能修改原始的
HttpServletRequest和HttpServletResponse對象。 - 簡單易用： 介面定義簡單，配置相對直觀。
- 無法訪問業務上下文： 過濾器只能訪問原始的HTTP請求和響應信息，無法直接獲取或操作MVC框架內部的業務上下文，例如Spring MVC中的Controller方法、ModelAndView對象等。
攔截器（Interceptor）深度解析
什麼是攔截器（Interceptor）？
攔截器（Interceptor）是基於特定框架（如Spring MVC、Struts2等）的組件，它在請求到達控制器（Controller）之前、控制器處理完畢之後、以及視圖渲染完畢之後執行。攔截器更深入地參與到框架的請求處理流程中，允許開發者在業務邏輯執行的不同階段進行干預。
它的核心作用在於：
- 在業務邏輯執行前、執行后以及視圖渲染后，對請求進行更細粒度的攔截和處理。
- 通常與框架內部的特定點（如處理器映射、處理器執行、視圖解析）緊密結合。
攔截器的工作原理
攔截器是AOP（面向切面編程）思想在Web框架中的一種體現。它們通常由框架來管理，並且能夠在請求處理的不同階段提供回調點。
以Spring MVC為例，一個攔截器通常包含以下三個核心方法：
preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)：在請求實際的處理器方法（Controller方法）執行之前調用。如果返回true，則請求會繼續執行後續的攔截器或處理器；如果返回false，則請求被中斷。postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView)：在處理器方法執行之後，但在視圖渲染之前調用。可以對ModelAndView對象進行修改，改變視圖或向視圖傳遞額外數據。afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)：在整個請求處理完成之後（包括視圖渲染完畢）調用，主要用於資源清理工作，例如關閉資料庫連接、釋放線程等。無論處理器方法是否拋出異常，此方法都會被執行。
常見應用場景：
- 用戶登錄校驗： 比過濾器更細緻，可以針對特定Controller或方法進行登錄狀態的檢查。
- 許可權控制： 根據用戶角色和訪問的URL或方法，進行更精細的許可權檢查。
- 日誌記錄與性能監控： 記錄請求處理的開始和結束時間，計算方法執行耗時。
- 數據綁定預處理： 在數據綁定到Model之前進行一些預處理或校驗。
- 國際化： 根據用戶的語言偏好設置Locale。
- 敏感詞過濾： 在數據提交到業務層之前進行敏感詞過濾。
攔截器的特點
- 基於特定框架： 與Spring MVC、Struts2等MVC框架緊密耦合，是框架的一部分。
- 更接近業務層： 能夠訪問到MVC框架的內部對象，如處理請求的
HandlerMethod（即Controller方法）、ModelAndView等，因此可以進行更業務相關的操作。 - 更靈活的生命周期控制： 提供了請求處理前、業務邏輯執行后、視圖渲染后等多個切入點，允許更精細的控制。
- 可操作MVC上下文： 可以直接操作
Model、View數據，甚至改變最終渲染的視圖。 - 對異常的處理：
afterCompletion方法在異常發生時也會被調用，便於異常處理和資源清理。
攔截器與過濾器的核心區別：多維度對比
現在，讓我們深入剖析攔截器和過濾器的區別，以便在實際開發中做出正確的選擇。
所處層次不同
過濾器（Filter）： 作用於Web容器（如Tomcat）層面，是Servlet規範的一部分。它在所有請求進入Web應用之前和所有響應離開Web應用之後生效，處於Web應用程序的最外層。可以形象地比喻為Web應用的「大門保安」，負責對進出大門的請求/響應進行初步檢查。
攔截器（Interceptor）： 作用於特定Web框架（如Spring MVC）層面，是框架的一部分。它在請求進入Controller層之前，或Controller處理完畢之後生效，處於Web應用內部的業務邏輯處理流程中。可以比喻為Controller層的「秘書或助理」，在業務邏輯處理前後提供服務。
這意味著過濾器對所有Servlet請求都有效，而攔截器只對經過其所在框架處理的請求有效。
規範與實現方式不同
- 過濾器： 是J2EE的Servlet規範的一部分，由Servlet容器實現和管理。所有支持Servlet規範的容器（如Tomcat, Jetty, JBoss等）都必須支持過濾器。
- 攔截器： 是特定Web框架（如Spring MVC、Struts2）自己實現和管理的，與Servlet規範無直接關係。不同的框架有不同的攔截器實現方式和API。
訪問上下文不同
- 過濾器： 只能訪問原始的
HttpServletRequest和HttpServletResponse對象。它無法直接獲取MVC框架內部的上下文信息，例如Spring MVC中的Controller方法對象（HandlerMethod）、ModelAndView對象、Spring的Bean等。 - 攔截器： 能夠訪問到更豐富的上下文信息。以Spring MVC為例，攔截器可以訪問到
Handler（通常是Controller中的處理方法）、ModelAndView等，從而可以更深入地介入到業務流程中，進行更細粒度的操作。
生命周期控制不同
- 過濾器： 主要是在請求的前後進行處理，即
doFilter方法中，通過chain.doFilter()來決定何時放行。 - 攔截器： 提供了更精細的生命周期控制點：
preHandle：在處理器方法執行之前。postHandle：在處理器方法執行之後，視圖渲染之前。afterCompletion：在整個請求處理完成（包括視圖渲染）之後，無論是否拋出異常都會執行。
應用場景側重點不同
- 過濾器： 更側重於對通用請求的預處理和后處理，通常用於與業務邏輯關係不那麼緊密的橫切關注點，如編碼、壓縮、全局日誌、安全（如XSS/SQL注入防護）等。它是一個「廣撒網」式的全局處理。
- 攔截器： 更側重於對業務邏輯相關的請求處理，通常用於更細粒度的業務控制和監控，如用戶登錄許可權校驗、性能監控、國際化、數據預處理、事務管理等。它是一個「精細化」的業務切面處理。
依賴關係不同
- 過濾器： 不依賴於任何MVC框架，只需Servlet容器支持即可。
- 攔截器： 強依賴於其所在的Web框架，脫離框架無法單獨使用。
何時選擇攔截器，何時選擇過濾器？
理解了攔截器和過濾器的區別后，如何在實際項目中做出選擇或協同使用它們就變得清晰了。
優先選擇過濾器（Filter）的場景：
- 當處理邏輯與Web框架無關，或者需要在請求進入任何Web組件之前就進行處理時（例如，處理靜態資源請求）。
- 需要進行全局性、通用性的操作，且不依賴於具體的業務邏輯或Controller上下文時，例如：
- 字元編碼轉換。
- 文件上傳下載、MIME類型處理。
- 全局的日誌記錄（如記錄所有HTTP請求和響應的原始數據）。
- 防跨站腳本攻擊（XSS）或SQL注入攻擊的統一防護。
- GZIP壓縮響應數據。
- IP黑白名單過濾。
- 當你的應用不使用任何特定的MVC框架，或者需要跨不同框架提供統一功能時。
優先選擇攔截器（Interceptor）的場景：
- 當處理邏輯與特定Web框架的內部機制或業務上下文緊密相關時。
- 需要對請求進行更細粒度、更接近業務層面的控制時，例如：
- 用戶登錄狀態和會話檢查，以及基於角色的許可權控制（因為可以訪問到請求映射的Handler信息）。
- 對請求的性能進行監控和統計（例如，統計某個Controller方法的執行時間）。
- 在Controller方法執行前後進行事務管理、數據源切換等AOP操作。
- 日誌記錄，但需要記錄業務相關的參數或結果。
- 統一異常處理（在
afterCompletion中進行）。 - 國際化處理，根據請求頭設置語言環境。
- 需要在請求處理的不同階段（請求前、業務處理后、視圖渲染后）執行不同邏輯時。
總結： 攔截器和過濾器並非互斥，它們可以在同一個應用程序中協同工作，各司其職。通常，過濾器處理更「粗粒度」的、底層的、與業務邏輯無關的請求；而攔截器處理更「細粒度」的、業務層面的、與框架耦合度高的請求。
常見問題（FAQ）
如何理解「攔截器和過濾器」在請求處理鏈路中的位置？
可以把整個Web應用的處理過程想象成一條生產線。過濾器（Filter）位於生產線的「入口處」，負責對所有進入工廠的原材料（HTTP請求）進行初步的安檢和預處理，無論這些原材料最終會被哪個車間處理。而攔截器（Interceptor）則位於工廠內部某個特定車間（例如Spring MVC處理流程）的特定工序點，它能夠更深入地參與到某個產品的加工過程中，對半成品（請求和業務數據）進行精細化處理，甚至改變其後續的流向。
為何說攔截器比過濾器「更接近業務」？
這是因為攔截器能夠訪問到Web框架內部的上下文信息，例如在Spring MVC中，攔截器可以獲取到即將執行的Controller方法（HandlerMethod）以及方法執行后的Model和View數據（ModelAndView）。通過這些信息，攔截器可以根據具體的業務邏輯（例如檢查用戶是否擁有訪問某個特定Controller方法的許可權）進行判斷和操作，而過濾器只能看到原始的HTTP請求和響應，無法直接觸及業務層面的信息。
如何在Spring Boot應用中同時配置攔截器和過濾器？
在Spring Boot中，配置過濾器通常通過實現javax.servlet.Filter介面並使用@Component或@WebFilter註解，或者通過FilterRegistrationBean進行註冊。配置攔截器則通常通過實現org.springframework.web.servlet.HandlerInterceptor介面，並將其註冊到WebMvcConfigurer的addInterceptors方法中。Spring Boot會自動識別並按順序載入這兩種組件。
攔截器和過濾器可以互相替代嗎？
在某些簡單的場景下，它們的功能可能看起來有重疊，例如都可以用於日誌記錄或簡單的許可權校驗。但從設計理念和所處層次來看，它們是不可互相替代的。過濾器無法訪問框架內部的業務上下文，而攔截器則無法在請求進入Servlet容器之前就進行處理。選擇哪一個取決於你需要處理的問題的性質和所處的層次。對於Web容器級別的通用問題，選擇過濾器；對於框架業務邏輯相關的特定問題，選擇攔截器。
為何有時只需要使用其中一種？
這取決於應用的具體需求。如果你的應用只需要進行一些與業務邏輯無關的全局性處理，例如字元編碼、請求頭修改、全局性日誌等，那麼過濾器就足夠了。但如果你的應用需要進行更細緻的業務許可權控制、性能監控、或在Controller執行前後進行數據處理等操作，那麼攔截器會是更合適的選擇，因為它能更深入地介入到業務處理流程中，並訪問到框架提供的豐富上下文信息。
