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