前一篇才提到過濾器的機制，這篇要提的是有類似概念的攔截器(Interceptor)，不過比起過濾器來說，攔截器更專注於攔截HTTP請求，更適合處理與API相關的邏輯，在請求進入API之前、執行API之後、返回響應之前，都能透過攔截器處理及干預。

使用場景

• 日誌記錄：紀錄請求與響應訊息，方便後續分析與追蹤。
• 身份驗證：進入API之前驗證用戶身分，檢查是否有對應權限。
• 請求修改：請求到達控制器之前，修改請求參數或訊息。
• 響應修改：響應返回給客戶端之前，修改響應內容。

使用方法

• 步驟一：自訂攔截器
  定義自訂攔截器類別，實現HandlerInterceptor介面：

public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String user = (String) request.getSession().getAttribute("user");
        if (user == null) {
            response.sendRedirect("/login");
            return false; // 終止請求
        }
        return true; // 繼續執行
    }
}

當用戶未登入時，就會重導到登入頁面。

• 步驟二：註冊攔截器
  放入要攔截的路徑給Spring Boot知道，使用WebMvcConfigurer設定：

@Configuration
public class webbConig extends WebMvcConfigurerAdapter {
	@Override
	pubic void addInterceptors(InterceptorRegistry registry) {
		registry.addInterceptor(new LoginInterceptor())
		.addPathPatterns("/**").excludePathPatterns("/","/login");
	}
}

每當要進入任何路徑都會檢查用戶權限，除非是/login或/。

攔截器與過濾器差異

攔截器跟過濾器一樣，屬於Spring MVC一部分，因此基於Spring應用都能使用；同樣地，在Spring Boot使用是近一步簡化配置流程，使用更加方便。
相較於攔截器(Interceptor)，過濾器其實是更適合底層的請求處理，像是全局的日誌請求、格式字符編碼等等，而攔截器專為HTTP請求設計，因此若要做會員驗證等機制，建議使用攔截器(Interceptor)。

當需求是要針對HTTP的請求進行處理，像是驗證或邏輯，直接使用攔截器實現即可；若是針對全局請求過濾或資料處理，使用過濾器會更適合唷！