，用流程圖定位問題)
SpringMVC 的工作流程大概是 Java 后端面試里出現(xiàn)頻率最高的問題也是很多開發(fā)者“背得下來卻用不上”的問題。我在實際排查問題的時候發(fā)現(xiàn)真正能把流程圖當成調(diào)試地圖的人處理起 404、400、參數(shù)丟失、視圖路徑錯誤這類問題會快很多而只背了一個大概流程的人遇到異常往往只能靠猜。這篇文章我不會按套路復述一遍流程而是把從請求進到 Servlet 容器開始一直到響應(yīng)返回這幾大步里每一個關(guān)鍵節(jié)點的作用、配套組件和常見故障點拆開講適合正在學 SpringMVC 的初學者、準備面試的人以及被各種 Web 層問題折磨過的后端開發(fā)者?？赐曛竽銜l(fā)現(xiàn)流程不是用來背的是用來定位問題的。1. 請求還沒進 Controller 前DispatcherServlet 是怎么被初始化的1.1 先分清兩個容器根容器和 DispatcherServlet 自己的容器很多人背流程時忽略了一個前提DispatcherServlet 本身是一個 Servlet它必須被 Servlet 容器加載并初始化之后才有后續(xù)的 HandlerMapping、 HandlerAdapter 這些事。在傳統(tǒng)的 XML 配置時代web.xml 里通常有兩段配置一段是 ContextLoaderListener一段是 DispatcherServlet。context-param param-namecontextConfigLocation/param-name param-valueclasspath:spring-root.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-valueclasspath:spring-mvc.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern//url-pattern /servlet-mappingContextLoaderListener 負責創(chuàng)建根 Spring 容器里面一般是 Service、DAO、數(shù)據(jù)源這些業(yè)務(wù)層組件DispatcherServlet 又會創(chuàng)建一個屬于它自己的 WebApplicationContext也就是子容器里面掃描 Controller、HandlerMapping、HandlerAdapter 這些 Web 層組件。子容器能夠訪問父容器的 Bean反過來父容器看不到子容器的 Bean。這個父子關(guān)系是很多人一開始忽略的坑Controller 里注入 Service 報 NoSuchBeanDefinitionException十有八九是 Service 掃描在了子容器范圍之外或者是根容器里壓根沒有這個 Bean?，F(xiàn)代基于注解的配置會把這一切簡化成繼承 AbstractAnnotationConfigDispatcherServletInitializer但底層機制沒有變getRootConfigClasses 返回的是根容器配置getServletConfigClasses 返回的是 DispatcherServlet 子容器配置getServletMappings 決定了這個 DispatcherServlet 攔截哪些請求。public class MyWebInitializer extends AbstractAnnotationConfigDispatcherServletInitializer { Override protected Class?[] getRootConfigClasses() { return new Class?[]{RootConfig.class}; } Override protected Class?[] getServletConfigClasses() { return new Class?[]{WebConfig.class}; } Override protected String[] getServletMappings() { return new String[]{/}; } }1.2 initStrategies 到底初始化了哪些“裝備”DispatcherServlet 繼承自 FrameworkServlet。FrameworkServlet 在容器刷新完成之后會調(diào)用 DispatcherServlet 的 onRefreshonRefresh 最終執(zhí)行 initStrategies。這個方法一次性初始化了流程里后面所有要用到的組件集合protected void initStrategies(ApplicationContext context) { initMultipartResolver(context); initLocaleResolver(context); initThemeResolver(context); initHandlerMappings(context); initHandlerAdapters(context); initHandlerExceptionResolvers(context); initRequestToViewNameTranslator(context); initViewResolvers(context); initFlashMapManager(context); }注意這些初始化的結(jié)果都是 List 或者單個組件存放在 DispatcherServlet 的成員變量里。比如 handlerMappings 是一個 ListHandlerMappinghandlerAdapters 是 ListHandlerAdapterhandlerExceptionResolvers 是 ListHandlerExceptionResolver。這也意味著你可以在配置里手動聲明自定義的 HandlerMapping、HandlerAdapter、ViewResolverSpringMVC 會把它們追加進集合并在流程中按 order 順序逐個嘗試。實際的請求到達時Servlet 容器調(diào)用 DispatcherServlet 的 service 方法FrameworkServlet 重寫了 doGet、doPost 等方法統(tǒng)一進入 processRequest再由 processRequest 轉(zhuǎn)到 doService最后進入 doDispatch。doDispatch 才是整個 SpringMVC 工作流程的主戰(zhàn)場后面所有環(huán)節(jié)都在這個方法里串聯(lián)起來。想調(diào)試 SpringMVC 問題時第一行斷點打在這里基本不會錯。2. HandlerMappingURL 是怎么和某個具體方法掛上鉤的2.1 映射表的注冊規(guī)則與匹配優(yōu)先級doDispatch 的第一件事是調(diào)用 getHandler(processedRequest)這個方法會遍歷 DispatcherServlet 持有的 handlerMappings 集合返回第一個找到的能匹配當前請求的 HandlerExecutionChain。默認情況下SpringMVC 注冊的是 RequestMappingHandlerMapping它在一開始啟動時就會掃描容器中所有標注了 Controller 的類把類上 RequestMapping 的路徑和方法上 RequestMapping 的路徑拼接起來得到一個完整的映射條件。這里有一個很多資料不會細講但實際排查時很關(guān)鍵的點一個請求能不能找到對應(yīng)方法不只是看路徑是否對得上。RequestMappingInfo 里還包含請求方法、參數(shù)條件、請求頭條件、produces、consumes。舉個例子你定義了 PostMapping(/user) 但用 GET 請求訪問HandlerMapping 是能找到這個映射的但匹配結(jié)果會包含“方法條件不滿足”最終由后續(xù)流程拋出 405而如果你的 URL 壓根沒匹配上任何路徑才會出現(xiàn) 404。路徑匹配的優(yōu)先級遵循“精確匹配優(yōu)先于通配符”的原則。比如 /user/{id} 和 /user/profile 同時存在訪問 /user/profile 時profile 的映射更具體會被選中。如果兩個映射的路徑完全一樣、請求條件也完全一樣Spring 啟動時就會直接報異常提示 Ambiguous mapping根本不會等到請求進來才出錯。日常開發(fā)里最常見的 404 原因無非是 Controller 沒有被掃描到、類上忘了加 Controller、路徑寫錯、訪問的 URL 帶了項目前綴而映射沒帶。2.2 返回的 handler 其實是一串攔截器鏈條getHandler 返回的類型不是 Method而是 HandlerExecutionChain。這個鏈條由兩部分組成一個是真正要執(zhí)行的 Handler也就是 Controller 里那個被映射的方法另一個是當前請求匹配到的一組攔截器 HandlerInterceptor。攔截器是根據(jù)請求路徑和 Handler 類型進行匹配的比如你配置了攔截器只攔截 /api/**那么訪問 /api/user 時這個攔截器就會出現(xiàn)在鏈條里。攔截器列表的存在意味著流程在這里會分出一個分支。一個匹配到的請求滿足攔截條件的話會先經(jīng)過攔截器 preHandle 才能到達 Controller后面執(zhí)行完還會走 postHandle 和 afterCompletion。很多權(quán)限控制的攔截器如果 preHandle 返回了 false流程會直接中止不會繼續(xù)調(diào)用 Controller這也解釋了為什么有時你的接口被“攔”掉了卻看不到 Controller 里的日志。另一個容易被忽略的細節(jié)是如果 getHandler 返回 null也就是所有 HandlerMapping 都沒有找到能處理當前請求的映射doDispatch 會執(zhí)行 noHandlerFound。默認情況下 SpringMVC 會直接返回 404如果你的 DispatcherServlet 設(shè)置了 throwExceptionIfNoHandlerFound 為 true這里就會拋出 NoHandlerFoundException進入后面的異常解析環(huán)節(jié)。這兩種處理方式對客戶端來說都是 404但在服務(wù)端日志和響應(yīng)的內(nèi)容上完全不一樣。3. HandlerAdapter 的適配過程你的 Controller 代碼在哪個環(huán)節(jié)被真正執(zhí)行3.1 為什么要引入適配器這一層拿到 HandlerExecutionChain 之后doDispatch 調(diào)用 getHandlerAdapter(mappedHandler.getHandler())它遍歷 handlerAdapters 集合找到 supports 方法返回 true 的那個適配器。這一步是很多講流程的人一句話帶過但實際很重要的設(shè)計。原因在于SpringMVC 的 Handler 并不只有一種形態(tài)。在注解驅(qū)動成為主流之前Handler 可以是實現(xiàn)了 Controller 接口的類方法簽名是 handleRequest(HttpServletRequest, HttpServletResponse)返回 ModelAndView也可以是 HttpRequestHandler直接操作 request 和 response現(xiàn)在最常見的是 RequestMapping 注解方法返回各種類型的對象。這三種 Handler 的調(diào)用方式完全不同如果不加一層適配器doDispatch 就必須寫一堆 if-else 去判斷 Handler 類型。適配器模式把“調(diào)用 Handler 的動作”抽象成統(tǒng)一的 handle 方法讓 DispatcherServlet 只需要面向 HandlerAdapter 編程。RequestMappingHandlerAdapter 就是為我們最常見的注解方法服務(wù)的適配器。它內(nèi)部會把 Handler 包裝成一個 HandlerMethod通過反射調(diào)用真實的 Controller 方法。這一步的復雜之處在于參數(shù)解析和返回值處理所以引出了下面這兩位關(guān)鍵的“門神”。3.2 參數(shù)解析器與返回值處理器數(shù)據(jù)進進出出的兩扇門RequestMappingHandlerAdapter 調(diào)用 HandlerMethod 時并不會直接 method.invoke(obj, args)而是先對每個參數(shù)調(diào)用 HandlerMethodArgumentResolver 來解析參數(shù)值。SpringMVC 內(nèi)置了二十多個參數(shù)解析器常見的有RequestParamMethodArgumentResolver處理 RequestParam 以及簡單類型的參數(shù)PathVariableMethodArgumentResolver處理 PathVariable 路徑變量RequestResponseBodyMethodProcessor處理 RequestBody同時它也是返回值處理器ModelAttributeMethodProcessor處理 ModelAttribute 和普通對象參數(shù)綁定ServletRequestMethodArgumentResolver直接注入 HttpServletRequest、HttpServletResponse每個解析器都有自己支持的參數(shù)類型SpringMVC 按順序遍歷第一個 supports 返回 true 的解析器會負責解析這個參數(shù)。這個機制解釋了大量開發(fā)中遇到的“詭異問題”。比如表單提交一個對象結(jié)果對象里的字段全部是 null往往就是參數(shù)名和 JavaBean 屬性對不上或者沒有開啟 javac 的 -parameters 參數(shù)導致解析器拿不到真實參數(shù)名再比如傳入 LocalDateTime 類型的參數(shù)卻直接報 400通常是沒有注冊對應(yīng)的類型轉(zhuǎn)換器或格式化器。方法調(diào)用結(jié)束后返回值處理器 HandlerMethodReturnValueHandler 負責決定這個返回值該怎么處理。方法返回一個 String處理器可能把它當成邏輯視圖名返回一個對象并且方法上有 ResponseBody處理器就會調(diào)用 HttpMessageConverter 把對象序列化成 JSON 寫回 response。所以“忘了加 ResponseBody 結(jié)果返回了一串視圖名字符串”這種問題本質(zhì)上是返回值處理器選擇錯了路徑。3.3 攔截器鏈在適配器執(zhí)行前后的排隊順序適配器真正調(diào)用 Controller 方法之前dispatch 會先執(zhí)行 mappedHandler.applyPreHandle。所有攔截器的 preHandle 按注冊順序正序執(zhí)行一旦某個 preHandle 返回 false流程立即終止終止后已執(zhí)行過 preHandle 的攔截器的 afterCompletion 會被觸發(fā)但還沒有執(zhí)行 preHandle 的攔截器之后不會再執(zhí)行。Controller 方法正常返回后執(zhí)行 applyPostHandle這里的順序是逆序也就是后注冊的攔截器先執(zhí)行 postHandle。這個“正序進入、逆序退出”的設(shè)計和 AOP 的調(diào)用鏈是同一個思想類似洋蔥模型最先包裹的切面最后退出。最后整個請求結(jié)束時會觸發(fā) applyAfterCompletion無論請求是正常完成還是拋出異常它都會執(zhí)行相當于 finally 塊。很多開發(fā)者在攔截器里做操作日志afterCompletion 記錄耗時和權(quán)限校驗preHandle 放行或攔截時必須理解這個順序否則日志時間順序會不對。4. 視圖渲染和 JSON 輸出請求結(jié)束前的最后分岔口4.1 視圖解析器如何把一個字符串變成真正的頁面如果 Controller 方法沒有 ResponseBody返回值會被當作邏輯視圖名處理。doDispatch 在拿到 ModelAndView 之后會調(diào)用 processDispatchResult其中通過 resolveViewName 遍歷 ViewResolver 集合找到能解析出 View 對象的解析器。最常見的 InternalResourceViewResolver 通常配置了前綴和后綴比如bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/views// property namesuffix value.jsp/ /bean方法返回 user/list解析器會把它拼成 /WEB-INF/views/user/list.jsp返回一個 InternalResourceView。View 對象負責真正的渲染render 方法把 Model 中的屬性展開為 request 屬性然后通過服務(wù)端轉(zhuǎn)發(fā) forward 到最終的 JSP 頁面。這也是 Model 數(shù)據(jù)能直接在 JSP 里用 request.getAttribute 取到的原因。這里有個細節(jié)為什么視圖文件放在 WEB-INF 下面因為 WEB-INF 目錄對客戶端是不可見的直接輸入 URL 無法訪問所有頁面必須經(jīng)過 Controller 才能渲染既能防止 JSP 源碼被直接訪問也能保證頁面渲染之前一定有某些業(yè)務(wù)邏輯被執(zhí)行過。如果視圖路徑少了前綴或后綴或者 JSP 文件不存在就會看到 500 錯誤而不是 404因為視圖解析器已經(jīng)找到了目標但 forward 時找不到資源。4.2 ResponseBody 為什么不用走視圖解析加了 ResponseBody 的方法返回值處理器直接選擇 RequestResponseBodyMethodProcessor它調(diào)用 writeWithMessageConverters從 HttpMessageConverter 列表里挑出一個能處理當前返回值類型和 Content-Type 的轉(zhuǎn)換器把對象序列化后寫入 response。Jackson 的 MappingJackson2HttpMessageConverter 就是負責把對象轉(zhuǎn) JSON 的那個轉(zhuǎn)換器。這個環(huán)節(jié)解釋了為什么有些 JSON 輸出問題跟 Controller 方法本身沒關(guān)系。對象里有循環(huán)引用序列化時直接 StackOverflowError對象字段沒有 getterJackson 序列化出來是空的LocalDateTime 沒有配置 JavaTimeModule序列化直接報錯。解決這些問題時你要意識到它們發(fā)生在視圖/響應(yīng)輸出階段而不是 Controller 調(diào)用階段排查方向自然不同。用 RestController 其實就相當于在類上加了 Controller 和 ResponseBody讓類下所有方法的返回值都走消息轉(zhuǎn)換器。4.3 靜態(tài)資源為什么會跑到 DispatcherServlet 手里DispatcherServlet 的 url-pattern 配置成 / 時它攔截除了 JSP 之外的所有請求包括 CSS、JS、圖片。這些靜態(tài)資源路徑在 HandlerMapping 里多半找不到對應(yīng)的 Controller 方法如果不加任何處理就會 404。SpringMVC 提供了兩個分支來解決mvc:resources 配置 ResourceHttpRequestHandler讓它從指定目錄查找靜態(tài)文件mvc:default-servlet-handler 把處理不了的回退給 Servlet 容器自帶的默認 Servlet。從流程的角度看靜態(tài)資源請求進入 DispatcherServlet 后正常 HandlerMapping 匹配不到于是走到 HandlerMapping 集合中那個專門處理靜態(tài)資源的 ResourceHandlerMapping如果配置了的話由它命中資源處理器。這個分支不在標準“Controller 流程”的敘事里但實際項目里靜態(tài)資源 404 成了最常見的問題之一值得記住它在流程中的位置。5. 出異常時流程并沒有停HandlerExceptionResolver 的分工與介入時機5.1 內(nèi)置異常解析器三件套分別處理什么doDispatch 的核心方法調(diào)用被一個 try-catch 包住如果 HandlerAdapter 執(zhí)行過程中拋出了異常會被捕獲到 dispatchException 變量中之后流程不會立刻返回而是進入 processDispatchResult再轉(zhuǎn) processHandlerException。processHandlerException 會遍歷 handlerExceptionResolvers 集合找出能處理當前異常的解析器。SpringMVC 默認注冊了三個異常解析器分工非常明確異常解析器負責的場景典型痛點ExceptionHandlerExceptionResolver處理 ExceptionHandler 注解標注的方法自定義業(yè)務(wù)異常統(tǒng)一返回結(jié)構(gòu)ResponseStatusExceptionResolver處理 ResponseStatus 注解的異常類或異常方法讓異常自動映射到指定 HTTP 狀態(tài)碼DefaultHandlerExceptionResolver處理 SpringMVC 自身拋出的標準異常請求方法不支持時轉(zhuǎn)為 405參數(shù)缺失時轉(zhuǎn)為 400這三個解析器按順序嘗試前一個能處理的話后面就不再介入。所以如果你自定義了 ControllerAdvice 里捕獲異常的處理邏輯流程通常會停在第一個解析器自定義 HandlerExceptionResolver 的場景反而比較少。5.2 ExceptionHandler 是怎么被找到的ControllerAdvice 本質(zhì)上是一個特殊的 Spring BeanSpringMVC 在初始化 ExceptionHandlerExceptionResolver 時會收集容器中所有 ControllerAdvice 注解的 Bean以及普通 Controller 內(nèi)部標注了 ExceptionHandler 的方法構(gòu)造成一個異常處理方法的映射表。當異常發(fā)生時解析器會根據(jù)異常類型在映射表中查找最匹配的處理方法匹配的優(yōu)先級是按繼承關(guān)系尋找最接近的異常類型。比如你同時定義了 ExceptionHandler(BusinessException.class) 和 ExceptionHandler(Exception.class)業(yè)務(wù)方法拋出 BusinessException那優(yōu)先執(zhí)行前者如果只定義了 Exception 級別的兜底方法那所有異常都會走到它那里。這里容易踩的坑是ExceptionHandler 方法所在類必須被 Spring 掃描到否則控制器異常根本不會進到你預(yù)想的處理邏輯。RestControllerAdvice 其實就是在 ControllerAdvice 的基礎(chǔ)上給默認方法加了 ResponseBody 語義返回的對象直接作為 JSON 響應(yīng)體輸出。5.3 異常情況下攔截器回調(diào)誰能收到攔截器回調(diào)與異常的關(guān)系也經(jīng)常被理解錯。如果 Controller 方法里拋了異常postHandle 不會執(zhí)行afterCompletion 會執(zhí)行并且能拿到異常對象。因為 postHandle 的設(shè)計意圖是“Controller 已經(jīng)正常返回后”的額外處理它無法感知異常而 afterCompletion 是請求結(jié)束的收尾點無論成功失敗都會觸發(fā)。還有一個細節(jié)如果第一個攔截器的 preHandle 返回 false那么第二個攔截器的 preHandle 不會執(zhí)行第一個攔截器自己的 afterCompletion 會執(zhí)行第二個攔截器的 afterCompletion 不會執(zhí)行。這是因為 HandlerExecutionChain 內(nèi)部記錄了已經(jīng)執(zhí)行過 preHandle 的攔截器列表afterCompletion 只回調(diào)這個列表中的攔截器。這個順序在做統(tǒng)一日志時非常重要否則你會在異常場景下看到攔截器日志缺失或者順序混亂誤以為是高并發(fā)丟日志實際是理解錯了流程結(jié)構(gòu)。6. 把流程圖當排查工具常見故障現(xiàn)象與定位斷點6.1 故障現(xiàn)象對流程環(huán)節(jié)的速查表在實際項目中我最常用到 SpringMVC 流程知識的場景不是面試而是給線上問題劃范圍。下面這張表是我自己排查 Web 層問題時常用的對照關(guān)系遇到現(xiàn)象先在里面找對應(yīng)環(huán)節(jié)再決定斷點打在哪故障現(xiàn)象問題大概率落在哪個環(huán)節(jié)排查切入點所有 Controller 路徑都 404HandlerMapping 匹配前Controller 沒掃描到、路徑前綴不對DispatcherServlet.doDispatch 中看 getHandler 返回值只有某個路徑 404HandlerMapping 匹配階段路徑映射寫錯或條件不匹配查看 RequestMapping 路徑和請求 URL啟動報 Ambiguous mappingHandlerMapping 注冊階段兩個映射條件完全一致檢查 Controller 方法上的注解路徑請求返回 401/403 或空白頁HandlerExecutionChain 攔截器 preHandle 返回 false檢查攔截器實現(xiàn)和日志400 Bad Request參數(shù)解析或類型轉(zhuǎn)換失敗、RequestBody 反序列化失敗適配器 invoke 前查看參數(shù)解析結(jié)果405 Method Not AllowedHandlerMapping 匹配到了路徑但請求方法不允許檢查 GetMapping/PostMapping 是否寫對500 No adapter for handlerHandlerAdapter 環(huán)節(jié)找不到合適適配器getHandlerAdapter 返回 null返回 JSON 卻變成視圖名/白標頁返回值處理器選錯忘了 ResponseBody檢查方法或類上注解靜態(tài)資源 404靜態(tài)資源處理分支未配置檢查 resources 或 default-servlet 配置JSON 循環(huán)引用、字段為空HttpMessageConverter 序列化階段檢查 Jackson 配置和對象結(jié)構(gòu)6.2 一次 404 的逐步排查復盤我曾經(jīng)接手過一個模擬項目的排查前端請求 GET /api/user/123服務(wù)器返回 404。表面看是路徑問題但實際排查鏈路可以完整走一遍流程。第一步在 doDispatch 第一行打斷點執(zhí)行到 getHandler 時看返回值。如果 mappedHandler 是 null說明 HandlerMapping 根本沒匹配上。接下來檢查三個方向Controller 類是否被組件掃描覆蓋到類上和方法上的路徑拼接后是否和 /api/user/123 一致以及是否存在路徑前綴比如配置了 server.servlet.context-path但前端忘了加。我這個例子里 Controller 方法寫的是 RequestMapping(/user/{id})類上沒有 RequestMapping但前端請求帶了多余前綴所以 getHandler 返回 null這個問題屬于典型路徑映射階段。如果 getHandler 返回了非空繼續(xù)看攔截器。某些自定義攔截器 preHandle 里直接 response.getWriter().write(no auth) 并返回 false客戶端看到的內(nèi)容取決于攔截器寫了什么如果啥都沒寫直接返回 false頁面可能就是一片空白或者被容器當成 404 處理。這時候 Controller 沒執(zhí)行日志里也沒有業(yè)務(wù)方法單看前端請求會非常困惑。過了攔截器之后如果 Controller 方法內(nèi)部拋了異常異常解析器會接管。假如你配置了 RestControllerAdvice 統(tǒng)一處理異常但返回的是 404 而不是 200那很可能異常處理方法根本沒命中異常被 DefaultHandlerExceptionResolver 轉(zhuǎn)換成了狀態(tài)碼。最終我那個模擬項目的問題就出在攔截器直接返回 false 且沒有寫任何響應(yīng)體瀏覽器看到的就是 404 白頁服務(wù)端日志什么都沒有排查時如果不按流程走很容易在 Controller 和路徑之間反復橫跳。6.3 調(diào)試 SpringMVC 流程時的斷點習慣按照流程排查問題時我自己的習慣是在幾個固定斷點觀察狀態(tài)而不是把整個流程從頭到尾單步跟一遍那樣太慢且容易暈。第一梯隊斷點是 DispatcherServlet.doDispatch() 入口看 mappedHandler 和后續(xù) mv、dispatchException 的狀態(tài)第二梯隊是 RequestMappingHandlerMapping.lookupHandlerMethod()看請求路徑匹配到了哪些候選映射第三梯隊是 InvocableMethod.invokeForRequest()看參數(shù)解析完成后真正傳入方法的值如果涉及 JSON 輸出還會在 RequestResponseBodyMethodProcessor.writeWithMessageConverters() 斷點看消息轉(zhuǎn)換器選擇和序列化的類型。這幾個斷點分別對應(yīng)流程中“映射-適配-視圖/響應(yīng)”三大核心階段出了任何問題基本都能較快定位。比如參數(shù)綁定出來是 null不用猜在 invokeForRequest 里能看到每個參數(shù)的解析結(jié)果比如 JSON 序列化報循環(huán)引用writeWithMessageConverters 會直接拋出異常一眼就知道不在 Controller 而在輸出階段。我自己在帶新同學或者排查線上問題的時候很少把流程從頭完整背一遍而是先想“現(xiàn)象落在哪個環(huán)節(jié)”404 大概率是 HandlerMapping 沒找到 handler400 大概率是參數(shù)解析沒通過返回類型不對大概率是返回值處理器選錯了路。腦子里的流程一旦和現(xiàn)象對應(yīng)上排查效率會高很多。如果你正在學 SpringMVC建議抽一個下午在 doDispatch 這幾個關(guān)鍵方法上打斷點把一次帶參數(shù)、帶攔截器、帶異常的真實請求完整走一遍那比背十遍流程圖都管用。 SpringMVC工作流程詳解：從請求到響應(yīng)，用流程圖定位問題
SpringMVC 的工作流程大概是 Java 后端面試里出現(xiàn)頻率最高的問題也是很多開發(fā)者“背得下來卻用不上”的問題。我在實際排查問題的時候發(fā)現(xiàn)真正能把流程圖當成調(diào)試地圖的人處理起 404、400、參數(shù)丟失、視圖路徑錯誤這類問題會快很多而只背了一個大概流程的人遇到異常往往只能靠猜。這篇文章我不會按套路復述一遍流程而是把從請求進到 Servlet 容器開始一直到響應(yīng)返回這幾大步里每一個關(guān)鍵節(jié)點的作用、配套組件和常見故障點拆開講適合正在學 SpringMVC 的初學者、準備面試的人以及被各種 Web 層問題折磨過的后端開發(fā)者?？赐曛竽銜l(fā)現(xiàn)流程不是用來背的是用來定位問題的。1. 請求還沒進 Controller 前DispatcherServlet 是怎么被初始化的1.1 先分清兩個容器根容器和 DispatcherServlet 自己的容器很多人背流程時忽略了一個前提DispatcherServlet 本身是一個 Servlet它必須被 Servlet 容器加載并初始化之后才有后續(xù)的 HandlerMapping、 HandlerAdapter 這些事。在傳統(tǒng)的 XML 配置時代web.xml 里通常有兩段配置一段是 ContextLoaderListener一段是 DispatcherServlet。context-param param-namecontextConfigLocation/param-name param-valueclasspath:spring-root.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-valueclasspath:spring-mvc.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern//url-pattern /servlet-mappingContextLoaderListener 負責創(chuàng)建根 Spring 容器里面一般是 Service、DAO、數(shù)據(jù)源這些業(yè)務(wù)層組件DispatcherServlet 又會創(chuàng)建一個屬于它自己的 WebApplicationContext也就是子容器里面掃描 Controller、HandlerMapping、HandlerAdapter 這些 Web 層組件。子容器能夠訪問父容器的 Bean反過來父容器看不到子容器的 Bean。這個父子關(guān)系是很多人一開始忽略的坑Controller 里注入 Service 報 NoSuchBeanDefinitionException十有八九是 Service 掃描在了子容器范圍之外或者是根容器里壓根沒有這個 Bean?，F(xiàn)代基于注解的配置會把這一切簡化成繼承 AbstractAnnotationConfigDispatcherServletInitializer但底層機制沒有變getRootConfigClasses 返回的是根容器配置getServletConfigClasses 返回的是 DispatcherServlet 子容器配置getServletMappings 決定了這個 DispatcherServlet 攔截哪些請求。public class MyWebInitializer extends AbstractAnnotationConfigDispatcherServletInitializer { Override protected Class?[] getRootConfigClasses() { return new Class?[]{RootConfig.class}; } Override protected Class?[] getServletConfigClasses() { return new Class?[]{WebConfig.class}; } Override protected String[] getServletMappings() { return new String[]{/}; } }1.2 initStrategies 到底初始化了哪些“裝備”DispatcherServlet 繼承自 FrameworkServlet。FrameworkServlet 在容器刷新完成之后會調(diào)用 DispatcherServlet 的 onRefreshonRefresh 最終執(zhí)行 initStrategies。這個方法一次性初始化了流程里后面所有要用到的組件集合protected void initStrategies(ApplicationContext context) { initMultipartResolver(context); initLocaleResolver(context); initThemeResolver(context); initHandlerMappings(context); initHandlerAdapters(context); initHandlerExceptionResolvers(context); initRequestToViewNameTranslator(context); initViewResolvers(context); initFlashMapManager(context); }注意這些初始化的結(jié)果都是 List 或者單個組件存放在 DispatcherServlet 的成員變量里。比如 handlerMappings 是一個 ListHandlerMappinghandlerAdapters 是 ListHandlerAdapterhandlerExceptionResolvers 是 ListHandlerExceptionResolver。這也意味著你可以在配置里手動聲明自定義的 HandlerMapping、HandlerAdapter、ViewResolverSpringMVC 會把它們追加進集合并在流程中按 order 順序逐個嘗試。實際的請求到達時Servlet 容器調(diào)用 DispatcherServlet 的 service 方法FrameworkServlet 重寫了 doGet、doPost 等方法統(tǒng)一進入 processRequest再由 processRequest 轉(zhuǎn)到 doService最后進入 doDispatch。doDispatch 才是整個 SpringMVC 工作流程的主戰(zhàn)場后面所有環(huán)節(jié)都在這個方法里串聯(lián)起來。想調(diào)試 SpringMVC 問題時第一行斷點打在這里基本不會錯。2. HandlerMappingURL 是怎么和某個具體方法掛上鉤的2.1 映射表的注冊規(guī)則與匹配優(yōu)先級doDispatch 的第一件事是調(diào)用 getHandler(processedRequest)這個方法會遍歷 DispatcherServlet 持有的 handlerMappings 集合返回第一個找到的能匹配當前請求的 HandlerExecutionChain。默認情況下SpringMVC 注冊的是 RequestMappingHandlerMapping它在一開始啟動時就會掃描容器中所有標注了 Controller 的類把類上 RequestMapping 的路徑和方法上 RequestMapping 的路徑拼接起來得到一個完整的映射條件。這里有一個很多資料不會細講但實際排查時很關(guān)鍵的點一個請求能不能找到對應(yīng)方法不只是看路徑是否對得上。RequestMappingInfo 里還包含請求方法、參數(shù)條件、請求頭條件、produces、consumes。舉個例子你定義了 PostMapping(/user) 但用 GET 請求訪問HandlerMapping 是能找到這個映射的但匹配結(jié)果會包含“方法條件不滿足”最終由后續(xù)流程拋出 405而如果你的 URL 壓根沒匹配上任何路徑才會出現(xiàn) 404。路徑匹配的優(yōu)先級遵循“精確匹配優(yōu)先于通配符”的原則。比如 /user/{id} 和 /user/profile 同時存在訪問 /user/profile 時profile 的映射更具體會被選中。如果兩個映射的路徑完全一樣、請求條件也完全一樣Spring 啟動時就會直接報異常提示 Ambiguous mapping根本不會等到請求進來才出錯。日常開發(fā)里最常見的 404 原因無非是 Controller 沒有被掃描到、類上忘了加 Controller、路徑寫錯、訪問的 URL 帶了項目前綴而映射沒帶。2.2 返回的 handler 其實是一串攔截器鏈條getHandler 返回的類型不是 Method而是 HandlerExecutionChain。這個鏈條由兩部分組成一個是真正要執(zhí)行的 Handler也就是 Controller 里那個被映射的方法另一個是當前請求匹配到的一組攔截器 HandlerInterceptor。攔截器是根據(jù)請求路徑和 Handler 類型進行匹配的比如你配置了攔截器只攔截 /api/**那么訪問 /api/user 時這個攔截器就會出現(xiàn)在鏈條里。攔截器列表的存在意味著流程在這里會分出一個分支。一個匹配到的請求滿足攔截條件的話會先經(jīng)過攔截器 preHandle 才能到達 Controller后面執(zhí)行完還會走 postHandle 和 afterCompletion。很多權(quán)限控制的攔截器如果 preHandle 返回了 false流程會直接中止不會繼續(xù)調(diào)用 Controller這也解釋了為什么有時你的接口被“攔”掉了卻看不到 Controller 里的日志。另一個容易被忽略的細節(jié)是如果 getHandler 返回 null也就是所有 HandlerMapping 都沒有找到能處理當前請求的映射doDispatch 會執(zhí)行 noHandlerFound。默認情況下 SpringMVC 會直接返回 404如果你的 DispatcherServlet 設(shè)置了 throwExceptionIfNoHandlerFound 為 true這里就會拋出 NoHandlerFoundException進入后面的異常解析環(huán)節(jié)。這兩種處理方式對客戶端來說都是 404但在服務(wù)端日志和響應(yīng)的內(nèi)容上完全不一樣。3. HandlerAdapter 的適配過程你的 Controller 代碼在哪個環(huán)節(jié)被真正執(zhí)行3.1 為什么要引入適配器這一層拿到 HandlerExecutionChain 之后doDispatch 調(diào)用 getHandlerAdapter(mappedHandler.getHandler())它遍歷 handlerAdapters 集合找到 supports 方法返回 true 的那個適配器。這一步是很多講流程的人一句話帶過但實際很重要的設(shè)計。原因在于SpringMVC 的 Handler 并不只有一種形態(tài)。在注解驅(qū)動成為主流之前Handler 可以是實現(xiàn)了 Controller 接口的類方法簽名是 handleRequest(HttpServletRequest, HttpServletResponse)返回 ModelAndView也可以是 HttpRequestHandler直接操作 request 和 response現(xiàn)在最常見的是 RequestMapping 注解方法返回各種類型的對象。這三種 Handler 的調(diào)用方式完全不同如果不加一層適配器doDispatch 就必須寫一堆 if-else 去判斷 Handler 類型。適配器模式把“調(diào)用 Handler 的動作”抽象成統(tǒng)一的 handle 方法讓 DispatcherServlet 只需要面向 HandlerAdapter 編程。RequestMappingHandlerAdapter 就是為我們最常見的注解方法服務(wù)的適配器。它內(nèi)部會把 Handler 包裝成一個 HandlerMethod通過反射調(diào)用真實的 Controller 方法。這一步的復雜之處在于參數(shù)解析和返回值處理所以引出了下面這兩位關(guān)鍵的“門神”。3.2 參數(shù)解析器與返回值處理器數(shù)據(jù)進進出出的兩扇門RequestMappingHandlerAdapter 調(diào)用 HandlerMethod 時并不會直接 method.invoke(obj, args)而是先對每個參數(shù)調(diào)用 HandlerMethodArgumentResolver 來解析參數(shù)值。SpringMVC 內(nèi)置了二十多個參數(shù)解析器常見的有RequestParamMethodArgumentResolver處理 RequestParam 以及簡單類型的參數(shù)PathVariableMethodArgumentResolver處理 PathVariable 路徑變量RequestResponseBodyMethodProcessor處理 RequestBody同時它也是返回值處理器ModelAttributeMethodProcessor處理 ModelAttribute 和普通對象參數(shù)綁定ServletRequestMethodArgumentResolver直接注入 HttpServletRequest、HttpServletResponse每個解析器都有自己支持的參數(shù)類型SpringMVC 按順序遍歷第一個 supports 返回 true 的解析器會負責解析這個參數(shù)。這個機制解釋了大量開發(fā)中遇到的“詭異問題”。比如表單提交一個對象結(jié)果對象里的字段全部是 null往往就是參數(shù)名和 JavaBean 屬性對不上或者沒有開啟 javac 的 -parameters 參數(shù)導致解析器拿不到真實參數(shù)名再比如傳入 LocalDateTime 類型的參數(shù)卻直接報 400通常是沒有注冊對應(yīng)的類型轉(zhuǎn)換器或格式化器。方法調(diào)用結(jié)束后返回值處理器 HandlerMethodReturnValueHandler 負責決定這個返回值該怎么處理。方法返回一個 String處理器可能把它當成邏輯視圖名返回一個對象并且方法上有 ResponseBody處理器就會調(diào)用 HttpMessageConverter 把對象序列化成 JSON 寫回 response。所以“忘了加 ResponseBody 結(jié)果返回了一串視圖名字符串”這種問題本質(zhì)上是返回值處理器選擇錯了路徑。3.3 攔截器鏈在適配器執(zhí)行前后的排隊順序適配器真正調(diào)用 Controller 方法之前dispatch 會先執(zhí)行 mappedHandler.applyPreHandle。所有攔截器的 preHandle 按注冊順序正序執(zhí)行一旦某個 preHandle 返回 false流程立即終止終止后已執(zhí)行過 preHandle 的攔截器的 afterCompletion 會被觸發(fā)但還沒有執(zhí)行 preHandle 的攔截器之后不會再執(zhí)行。Controller 方法正常返回后執(zhí)行 applyPostHandle這里的順序是逆序也就是后注冊的攔截器先執(zhí)行 postHandle。這個“正序進入、逆序退出”的設(shè)計和 AOP 的調(diào)用鏈是同一個思想類似洋蔥模型最先包裹的切面最后退出。最后整個請求結(jié)束時會觸發(fā) applyAfterCompletion無論請求是正常完成還是拋出異常它都會執(zhí)行相當于 finally 塊。很多開發(fā)者在攔截器里做操作日志afterCompletion 記錄耗時和權(quán)限校驗preHandle 放行或攔截時必須理解這個順序否則日志時間順序會不對。4. 視圖渲染和 JSON 輸出請求結(jié)束前的最后分岔口4.1 視圖解析器如何把一個字符串變成真正的頁面如果 Controller 方法沒有 ResponseBody返回值會被當作邏輯視圖名處理。doDispatch 在拿到 ModelAndView 之后會調(diào)用 processDispatchResult其中通過 resolveViewName 遍歷 ViewResolver 集合找到能解析出 View 對象的解析器。最常見的 InternalResourceViewResolver 通常配置了前綴和后綴比如bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/views// property namesuffix value.jsp/ /bean方法返回 user/list解析器會把它拼成 /WEB-INF/views/user/list.jsp返回一個 InternalResourceView。View 對象負責真正的渲染render 方法把 Model 中的屬性展開為 request 屬性然后通過服務(wù)端轉(zhuǎn)發(fā) forward 到最終的 JSP 頁面。這也是 Model 數(shù)據(jù)能直接在 JSP 里用 request.getAttribute 取到的原因。這里有個細節(jié)為什么視圖文件放在 WEB-INF 下面因為 WEB-INF 目錄對客戶端是不可見的直接輸入 URL 無法訪問所有頁面必須經(jīng)過 Controller 才能渲染既能防止 JSP 源碼被直接訪問也能保證頁面渲染之前一定有某些業(yè)務(wù)邏輯被執(zhí)行過。如果視圖路徑少了前綴或后綴或者 JSP 文件不存在就會看到 500 錯誤而不是 404因為視圖解析器已經(jīng)找到了目標但 forward 時找不到資源。4.2 ResponseBody 為什么不用走視圖解析加了 ResponseBody 的方法返回值處理器直接選擇 RequestResponseBodyMethodProcessor它調(diào)用 writeWithMessageConverters從 HttpMessageConverter 列表里挑出一個能處理當前返回值類型和 Content-Type 的轉(zhuǎn)換器把對象序列化后寫入 response。Jackson 的 MappingJackson2HttpMessageConverter 就是負責把對象轉(zhuǎn) JSON 的那個轉(zhuǎn)換器。這個環(huán)節(jié)解釋了為什么有些 JSON 輸出問題跟 Controller 方法本身沒關(guān)系。對象里有循環(huán)引用序列化時直接 StackOverflowError對象字段沒有 getterJackson 序列化出來是空的LocalDateTime 沒有配置 JavaTimeModule序列化直接報錯。解決這些問題時你要意識到它們發(fā)生在視圖/響應(yīng)輸出階段而不是 Controller 調(diào)用階段排查方向自然不同。用 RestController 其實就相當于在類上加了 Controller 和 ResponseBody讓類下所有方法的返回值都走消息轉(zhuǎn)換器。4.3 靜態(tài)資源為什么會跑到 DispatcherServlet 手里DispatcherServlet 的 url-pattern 配置成 / 時它攔截除了 JSP 之外的所有請求包括 CSS、JS、圖片。這些靜態(tài)資源路徑在 HandlerMapping 里多半找不到對應(yīng)的 Controller 方法如果不加任何處理就會 404。SpringMVC 提供了兩個分支來解決mvc:resources 配置 ResourceHttpRequestHandler讓它從指定目錄查找靜態(tài)文件mvc:default-servlet-handler 把處理不了的回退給 Servlet 容器自帶的默認 Servlet。從流程的角度看靜態(tài)資源請求進入 DispatcherServlet 后正常 HandlerMapping 匹配不到于是走到 HandlerMapping 集合中那個專門處理靜態(tài)資源的 ResourceHandlerMapping如果配置了的話由它命中資源處理器。這個分支不在標準“Controller 流程”的敘事里但實際項目里靜態(tài)資源 404 成了最常見的問題之一值得記住它在流程中的位置。5. 出異常時流程并沒有停HandlerExceptionResolver 的分工與介入時機5.1 內(nèi)置異常解析器三件套分別處理什么doDispatch 的核心方法調(diào)用被一個 try-catch 包住如果 HandlerAdapter 執(zhí)行過程中拋出了異常會被捕獲到 dispatchException 變量中之后流程不會立刻返回而是進入 processDispatchResult再轉(zhuǎn) processHandlerException。processHandlerException 會遍歷 handlerExceptionResolvers 集合找出能處理當前異常的解析器。SpringMVC 默認注冊了三個異常解析器分工非常明確異常解析器負責的場景典型痛點ExceptionHandlerExceptionResolver處理 ExceptionHandler 注解標注的方法自定義業(yè)務(wù)異常統(tǒng)一返回結(jié)構(gòu)ResponseStatusExceptionResolver處理 ResponseStatus 注解的異常類或異常方法讓異常自動映射到指定 HTTP 狀態(tài)碼DefaultHandlerExceptionResolver處理 SpringMVC 自身拋出的標準異常請求方法不支持時轉(zhuǎn)為 405參數(shù)缺失時轉(zhuǎn)為 400這三個解析器按順序嘗試前一個能處理的話后面就不再介入。所以如果你自定義了 ControllerAdvice 里捕獲異常的處理邏輯流程通常會停在第一個解析器自定義 HandlerExceptionResolver 的場景反而比較少。5.2 ExceptionHandler 是怎么被找到的ControllerAdvice 本質(zhì)上是一個特殊的 Spring BeanSpringMVC 在初始化 ExceptionHandlerExceptionResolver 時會收集容器中所有 ControllerAdvice 注解的 Bean以及普通 Controller 內(nèi)部標注了 ExceptionHandler 的方法構(gòu)造成一個異常處理方法的映射表。當異常發(fā)生時解析器會根據(jù)異常類型在映射表中查找最匹配的處理方法匹配的優(yōu)先級是按繼承關(guān)系尋找最接近的異常類型。比如你同時定義了 ExceptionHandler(BusinessException.class) 和 ExceptionHandler(Exception.class)業(yè)務(wù)方法拋出 BusinessException那優(yōu)先執(zhí)行前者如果只定義了 Exception 級別的兜底方法那所有異常都會走到它那里。這里容易踩的坑是ExceptionHandler 方法所在類必須被 Spring 掃描到否則控制器異常根本不會進到你預(yù)想的處理邏輯。RestControllerAdvice 其實就是在 ControllerAdvice 的基礎(chǔ)上給默認方法加了 ResponseBody 語義返回的對象直接作為 JSON 響應(yīng)體輸出。5.3 異常情況下攔截器回調(diào)誰能收到攔截器回調(diào)與異常的關(guān)系也經(jīng)常被理解錯。如果 Controller 方法里拋了異常postHandle 不會執(zhí)行afterCompletion 會執(zhí)行并且能拿到異常對象。因為 postHandle 的設(shè)計意圖是“Controller 已經(jīng)正常返回后”的額外處理它無法感知異常而 afterCompletion 是請求結(jié)束的收尾點無論成功失敗都會觸發(fā)。還有一個細節(jié)如果第一個攔截器的 preHandle 返回 false那么第二個攔截器的 preHandle 不會執(zhí)行第一個攔截器自己的 afterCompletion 會執(zhí)行第二個攔截器的 afterCompletion 不會執(zhí)行。這是因為 HandlerExecutionChain 內(nèi)部記錄了已經(jīng)執(zhí)行過 preHandle 的攔截器列表afterCompletion 只回調(diào)這個列表中的攔截器。這個順序在做統(tǒng)一日志時非常重要否則你會在異常場景下看到攔截器日志缺失或者順序混亂誤以為是高并發(fā)丟日志實際是理解錯了流程結(jié)構(gòu)。6. 把流程圖當排查工具常見故障現(xiàn)象與定位斷點6.1 故障現(xiàn)象對流程環(huán)節(jié)的速查表在實際項目中我最常用到 SpringMVC 流程知識的場景不是面試而是給線上問題劃范圍。下面這張表是我自己排查 Web 層問題時常用的對照關(guān)系遇到現(xiàn)象先在里面找對應(yīng)環(huán)節(jié)再決定斷點打在哪故障現(xiàn)象問題大概率落在哪個環(huán)節(jié)排查切入點所有 Controller 路徑都 404HandlerMapping 匹配前Controller 沒掃描到、路徑前綴不對DispatcherServlet.doDispatch 中看 getHandler 返回值只有某個路徑 404HandlerMapping 匹配階段路徑映射寫錯或條件不匹配查看 RequestMapping 路徑和請求 URL啟動報 Ambiguous mappingHandlerMapping 注冊階段兩個映射條件完全一致檢查 Controller 方法上的注解路徑請求返回 401/403 或空白頁HandlerExecutionChain 攔截器 preHandle 返回 false檢查攔截器實現(xiàn)和日志400 Bad Request參數(shù)解析或類型轉(zhuǎn)換失敗、RequestBody 反序列化失敗適配器 invoke 前查看參數(shù)解析結(jié)果405 Method Not AllowedHandlerMapping 匹配到了路徑但請求方法不允許檢查 GetMapping/PostMapping 是否寫對500 No adapter for handlerHandlerAdapter 環(huán)節(jié)找不到合適適配器getHandlerAdapter 返回 null返回 JSON 卻變成視圖名/白標頁返回值處理器選錯忘了 ResponseBody檢查方法或類上注解靜態(tài)資源 404靜態(tài)資源處理分支未配置檢查 resources 或 default-servlet 配置JSON 循環(huán)引用、字段為空HttpMessageConverter 序列化階段檢查 Jackson 配置和對象結(jié)構(gòu)6.2 一次 404 的逐步排查復盤我曾經(jīng)接手過一個模擬項目的排查前端請求 GET /api/user/123服務(wù)器返回 404。表面看是路徑問題但實際排查鏈路可以完整走一遍流程。第一步在 doDispatch 第一行打斷點執(zhí)行到 getHandler 時看返回值。如果 mappedHandler 是 null說明 HandlerMapping 根本沒匹配上。接下來檢查三個方向Controller 類是否被組件掃描覆蓋到類上和方法上的路徑拼接后是否和 /api/user/123 一致以及是否存在路徑前綴比如配置了 server.servlet.context-path但前端忘了加。我這個例子里 Controller 方法寫的是 RequestMapping(/user/{id})類上沒有 RequestMapping但前端請求帶了多余前綴所以 getHandler 返回 null這個問題屬于典型路徑映射階段。如果 getHandler 返回了非空繼續(xù)看攔截器。某些自定義攔截器 preHandle 里直接 response.getWriter().write(no auth) 并返回 false客戶端看到的內(nèi)容取決于攔截器寫了什么如果啥都沒寫直接返回 false頁面可能就是一片空白或者被容器當成 404 處理。這時候 Controller 沒執(zhí)行日志里也沒有業(yè)務(wù)方法單看前端請求會非常困惑。過了攔截器之后如果 Controller 方法內(nèi)部拋了異常異常解析器會接管。假如你配置了 RestControllerAdvice 統(tǒng)一處理異常但返回的是 404 而不是 200那很可能異常處理方法根本沒命中異常被 DefaultHandlerExceptionResolver 轉(zhuǎn)換成了狀態(tài)碼。最終我那個模擬項目的問題就出在攔截器直接返回 false 且沒有寫任何響應(yīng)體瀏覽器看到的就是 404 白頁服務(wù)端日志什么都沒有排查時如果不按流程走很容易在 Controller 和路徑之間反復橫跳。6.3 調(diào)試 SpringMVC 流程時的斷點習慣按照流程排查問題時我自己的習慣是在幾個固定斷點觀察狀態(tài)而不是把整個流程從頭到尾單步跟一遍那樣太慢且容易暈。第一梯隊斷點是 DispatcherServlet.doDispatch() 入口看 mappedHandler 和后續(xù) mv、dispatchException 的狀態(tài)第二梯隊是 RequestMappingHandlerMapping.lookupHandlerMethod()看請求路徑匹配到了哪些候選映射第三梯隊是 InvocableMethod.invokeForRequest()看參數(shù)解析完成后真正傳入方法的值如果涉及 JSON 輸出還會在 RequestResponseBodyMethodProcessor.writeWithMessageConverters() 斷點看消息轉(zhuǎn)換器選擇和序列化的類型。這幾個斷點分別對應(yīng)流程中“映射-適配-視圖/響應(yīng)”三大核心階段出了任何問題基本都能較快定位。比如參數(shù)綁定出來是 null不用猜在 invokeForRequest 里能看到每個參數(shù)的解析結(jié)果比如 JSON 序列化報循環(huán)引用writeWithMessageConverters 會直接拋出異常一眼就知道不在 Controller 而在輸出階段。我自己在帶新同學或者排查線上問題的時候很少把流程從頭完整背一遍而是先想“現(xiàn)象落在哪個環(huán)節(jié)”404 大概率是 HandlerMapping 沒找到 handler400 大概率是參數(shù)解析沒通過返回類型不對大概率是返回值處理器選錯了路。腦子里的流程一旦和現(xiàn)象對應(yīng)上排查效率會高很多。如果你正在學 SpringMVC建議抽一個下午在 doDispatch 這幾個關(guān)鍵方法上打斷點把一次帶參數(shù)、帶攔截器、帶異常的真實請求完整走一遍那比背十遍流程圖都管用。