之前的文章介紹過兩個攔截器（分別參考MyBatis功能點之二（2）：從責任鏈設計模式的角度理解外掛實現技術和Spring AOP之原始碼分析）。本文介紹的攔截器實現與它們有何異同呢？
在Spring MVC攔截器(Interceptor)使用中已知實現了HandlerInterceptor介面，MVC會自動攔截。如何實現的呢？改造文章中Spring MVC攔截器(Interceptor)使用的專案使用Spring MVC，不使用Spring Boot的自動配置研究MVC中的攔截器。
在配置類中增加攔截器：
攔截器怎麼使用的呢？在DispatcherServlet類中可以發現它們的蹤跡：
doDispatch方法中：
從上各圖中可以解釋Spring MVC攔截器(Interceptor)使用中的第一張圖：三次攔截的時機點。那麼這個mappedHandler是啥呢？是HandlerExecutionChain
看類名是不是就想到了責任鏈模式，這裡的使用與MyBatis功能點之二（2）：從責任鏈設計模式的角度理解外掛實現技術中的類似呢？看具體實現：
與MyBatis中實現一樣就是責任鏈模式的應用。那麼interceptorIndex在哪裡裝載的呢？
在initMapping操作時就載入了interceptor。這就與Mybatis中對於攔截器的應用一樣，兩個都有一個問題：就是那麼多的interceptors，哪個先執行哪個後執行呢？後續有案例可以分析繼續分享。
補充：不是本文重點內容，但是實際改造專案的過程中還是遇到了一些問題比較耗時，記錄如下：
1、同樣的資料庫配置和操作在一個專案中可以成功，在這個專案中沒有成功(不影響研究攔截器，本文寫完為止還沒有找到原因)；
2、關於資料庫和資原始檔訪問的配置，都是透過JavaBean的方式處理，相對Spring Boot寫簡單的配置檔案而言需要熟悉MVC中的一些元件；
3、關於jsp檔案中taglib，提交訪問請求總是提示jstl相關內容有問題。檢查關於ViewResolver的配置沒有問題，在看看jsp檔案果然有紅色。處理方法很簡單——直接把taglib的內容註釋了。
所以也充分說明之前成功執行的專案後續不一定能繼續成功執行不是沒有原因的。
4、在打war包的過程中，配置<directory>E:\ApachePro\apache-tomcat-10.1.19\webapps</directory>的進行打包與不配置在tomcat中有差別。開始使用<directory>E:\ApachePro\apache-tomcat-10.1.19\webapps</directory>，但是總是有問題，後來註釋了反而沒問題。不知道什麼原因，還沒有研究——之前這樣用沒有發現類似的問題。
5、訪問url細節問題。關於url，8080後面一定要新增finalName中的內容，在新增controler類中的mapping內容，不然總是提示404.