求流程核心組件深入解析)
1. 從一次請(qǐng)求說(shuō)起整體鏈路設(shè)計(jì)1.1 為什么需要一個(gè)統(tǒng)一前端控制器很多剛接觸 Java Web 的開(kāi)發(fā)者最早寫(xiě)的是 Servlet一個(gè)請(qǐng)求進(jìn)來(lái)根據(jù) URL 手動(dòng)判斷走哪個(gè)類(lèi)、調(diào)用哪個(gè)方法再到最后手動(dòng) setContentType、getWriter() 輸出 HTML。這種方式最大的問(wèn)題不在代碼量大而在“職責(zé)混亂”路由、參數(shù)解析、業(yè)務(wù)調(diào)用、響應(yīng)輸出全都揉在一個(gè)類(lèi)里改一個(gè) URL 規(guī)則就得動(dòng)業(yè)務(wù)代碼耦合高到讓人頭疼。Spring MVC 的出現(xiàn)本質(zhì)上就是想解決這個(gè)混亂。它把所有請(qǐng)求先交到一個(gè)統(tǒng)一入口——DispatcherServlet再去分發(fā)到具體的業(yè)務(wù)方法。這就是“前端控制器”模式。其實(shí)同類(lèi)型的思想在很多框架里都能看到比如 Struts、JSF 里也有類(lèi)似的集中分發(fā)組件但 Spring MVC 把這件事做得更干凈組件拆得更細(xì)擴(kuò)展點(diǎn)也更多。面試中如果被問(wèn)到“Spring MVC 請(qǐng)求流程”大概率不是想聽(tīng)你背幾個(gè)類(lèi)的名字而是想確認(rèn)你是否清楚一條請(qǐng)求從瀏覽器發(fā)起到響應(yīng)返回中間被拆成了哪些階段、每個(gè)階段由誰(shuí)負(fù)責(zé)、哪個(gè)環(huán)節(jié)是固定流程、哪個(gè)環(huán)節(jié)可以靈活擴(kuò)展。把這些回答透了比單純背出 DispatcherServlet、HandlerMapping、HandlerAdapter 這幾個(gè)單詞要有說(shuō)服力得多。1.2 請(qǐng)求流程的核心鏈路總覽先給一個(gè)最簡(jiǎn)版的總覽方便后面逐層展開(kāi)。一個(gè)標(biāo)準(zhǔn) Spring MVC 請(qǐng)求大致會(huì)經(jīng)過(guò)下面幾個(gè)階段請(qǐng)求到達(dá) DispatcherServlet框架拿到 HttpServletRequest 和 HttpServletResponse。DispatcherServlet 調(diào)用 HandlerMapping根據(jù)請(qǐng)求路徑、請(qǐng)求方法等條件找到能處理這個(gè)請(qǐng)求的 Handler通常是一個(gè) Controller 方法。DispatcherServlet 調(diào)用 HandlerAdapter 去執(zhí)行這個(gè) Handler。在執(zhí)行前后還可能經(jīng)過(guò)攔截器鏈Interceptor Chain。Controller 方法執(zhí)行業(yè)務(wù)邏輯返回一個(gè) ModelAndView或者使用 ResponseBody 直接寫(xiě)出響應(yīng)體。DispatcherServlet 把結(jié)果交給 ViewResolver 解析得到 View 對(duì)象并渲染輸出如果走的是 JSON 等消息轉(zhuǎn)換則由 HttpMessageConverter 完成輸出。簡(jiǎn)單理解DispatcherServlet 就像公司前臺(tái)它不干具體業(yè)務(wù)只負(fù)責(zé)接待、分配、協(xié)調(diào)資源HandlerMapping 相當(dāng)于內(nèi)部通訊錄負(fù)責(zé)查哪個(gè)部門(mén)來(lái)辦這件事HandlerAdapter 相當(dāng)于部門(mén)里具體干活的人不同的 Controller 方法形態(tài)需要不同的執(zhí)行方式ViewResolver 則像排版師傅負(fù)責(zé)把結(jié)果整理成客戶(hù)看得懂的樣子。這個(gè)流程用大白話(huà)說(shuō)并不難難的是把幾個(gè)關(guān)鍵組件之間的協(xié)作和邊界說(shuō)清。很多開(kāi)發(fā)者能說(shuō)出大概鏈條但不能解釋 HandlerAdapter 為什么要存在或者說(shuō)不出攔截器到底在哪個(gè)階段執(zhí)行。這些細(xì)節(jié)才是面試官區(qū)分你“背過(guò)答案”和“真懂原理”的關(guān)鍵點(diǎn)。1.3 請(qǐng)求流程的組件職責(zé)劃分先把核心組件的職責(zé)講透后面才能順暢地看源碼和實(shí)操。DispatcherServlet 是 Spring MVC 的門(mén)面它繼承自 FrameworkServlet再往上繼承 HttpServletBean 和 HttpServlet。它在初始化時(shí)會(huì)收集 WebApplicationContext 中所有相關(guān)組件包括 HandlerMapping、HandlerAdapter、ViewResolver、LocaleResolver、ThemeResolver、HandlerExceptionResolver 等并在 doDispatch 中把它們組合起來(lái)完成一次請(qǐng)求處理。HandlerMapping 負(fù)責(zé)“請(qǐng)求到方法的映射”。最常見(jiàn)的是 RequestMappingHandlerMapping它掃描 RequestMapping 注解把請(qǐng)求路徑、HTTP 方法、參數(shù)條件等內(nèi)容映射到 Controller 的 Method并緩存起來(lái)。匹配時(shí)需要處理路徑變量、通配符、produces/consumes 條件等。Spring 會(huì)持有多個(gè) HandlerMapping按順序逐個(gè)嘗試拿到第一個(gè)能處理的就返回。HandlerAdapter 負(fù)責(zé)“調(diào)用真正的處理邏輯”。有人會(huì)問(wèn)既然 Handler 都已經(jīng)找到 Controller 方法了為什么不直接反射調(diào)用還要再套一層適配器原因是 Controller 方法的定義方式太靈活了可能是普通的無(wú)參方法可能帶 RequestBody 參數(shù)可能返回 String、ModelAndView、ResponseEntity也可能是 Callable 或 DeferredResult 異步返回。Adapter 的作用就是把不同的方法形態(tài)統(tǒng)一適配成 ModelAndView 或 ResponseBody 結(jié)果。RequestMappingHandlerAdapter 是核心實(shí)現(xiàn)它內(nèi)部會(huì)處理參數(shù)解析器和返回值處理器。ViewResolver 負(fù)責(zé)把邏輯視圖名解析成具體的 View。常見(jiàn)的有 InternalResourceViewResolver它把 “user/list” 拼接成 “/WEB-INF/views/user/list.jsp” 這樣的真實(shí)路徑。還有 Thymeleaf 的視圖解析器、FreeMarker 的視圖解析器等。View 對(duì)象拿到模型數(shù)據(jù)后做模板渲染然后輸出到 Response。這四類(lèi)組件是 Spring MVC 的核心骨架。理解它們之間的層次關(guān)系再去看請(qǐng)求流程就不會(huì)糊。下面的章節(jié)我會(huì)逐階段拆流程把配置、源碼、實(shí)操、踩坑揉在一起講。2. 請(qǐng)求流程各階段細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 請(qǐng)求到達(dá)與處理器映射先看請(qǐng)求進(jìn)來(lái)那一刻發(fā)生了什么。容器在 web.xml 或通過(guò) Servlet 注解把 DispatcherServlet 映射到 “/” 路徑所以所有請(qǐng)求都會(huì)先落到它的 service 方法。FrameworkServlet 重寫(xiě)了 service()把 GET、POST、PUT、DELETE 等請(qǐng)求統(tǒng)一交給 processRequest() 處理。processRequest 里做幾件重要的事設(shè)置 LocaleContext、裝配 RequestAttributes、注冊(cè)可銷(xiāo)毀回調(diào)然后調(diào)用 doService()最后恢復(fù)現(xiàn)場(chǎng)。這里有個(gè)容易被忽視的細(xì)節(jié)請(qǐng)求參數(shù)、Locale 等上下文會(huì)被綁定到當(dāng)前線(xiàn)程方便后續(xù)代碼通過(guò) RequestContextHolder 訪(fǎng)問(wèn)。接下來(lái)進(jìn)入 DispatcherServlet 的 doService()。它把一些常用屬性塞進(jìn) request 的 attribute 中比如 webApplicationContext、localeResolver、themeResolver 等然后調(diào)用 doDispatch()。doDispatch 是整個(gè)流程的核心幾乎所有關(guān)鍵組件的調(diào)用都發(fā)生在這里。從這一層開(kāi)始你才能在源碼里真正看清 HandlerMapping 和 HandlerAdapter 是如何協(xié)作的。HandlerMapping 大多數(shù)項(xiàng)目里只有一個(gè) RequestMappingHandlerMapping但在復(fù)雜工程中可能有多個(gè)。Spring 會(huì)維護(hù)一個(gè)按 order 排序的列表依次調(diào)用 getHandler(request) 方法拿到第一個(gè)非空結(jié)果就用。getHandler 內(nèi)部會(huì)讓每個(gè) HandlerMapping 去計(jì)算 handler 和攔截器鏈最后返回一個(gè) HandlerExecutionChain。注意HandlerExecutionChain 里除了 handler 本身還包含匹配到的所有 HandlerInterceptor。HandMapping 匹配時(shí)需要處理路徑變量提取、正則表達(dá)式匹配、consumes 與 produces 條件判斷。比如 RequestMapping(value /api/user/{id}, method RequestMethod.GET, produces application/json)那么請(qǐng)求路徑 /api/user/123 且 Accept 頭包含 application/json 時(shí)才能命中。處理失敗則返回 null繼續(xù)下一個(gè)映射器。實(shí)操中比較常見(jiàn)的坑是路徑匹配規(guī)則和靜態(tài)資源沖突。很多項(xiàng)目在配置 DispatcherServlet 時(shí)映射到 “/”導(dǎo)致靜態(tài)資源 JS/CSS 也被當(dāng)成動(dòng)態(tài)請(qǐng)求處理出現(xiàn) 404。解決辦法是使用 mvc:resources 或 WebMvcConfigurer 中的 addResourceHandlers 顯式聲明靜態(tài)資源映射讓默認(rèn) Servlet 處理。另一個(gè)坑是 URL 大小寫(xiě)問(wèn)題Spring 默認(rèn)區(qū)分大小寫(xiě)如果你在 Linux 上部署把 /Api/User 寫(xiě)成 /api/user 就會(huì)匹配失敗但本地 Windows 又發(fā)現(xiàn)沒(méi)問(wèn)題容易讓人摸不著頭腦。2.2 參數(shù)綁定與類(lèi)型轉(zhuǎn)換在 HandlerMapping 找到目標(biāo)方法之后真正調(diào)用方法之前需要先解決一個(gè)問(wèn)題方法的參數(shù)從哪里來(lái)Spring MVC 在這兒設(shè)計(jì)了一套非常靈活的機(jī)制那就是 HandlerMethodArgumentResolver。每一種參數(shù)類(lèi)型都可以有對(duì)應(yīng)的解析器比如 PathVariable 由 PathVariableMethodArgumentResolver 處理RequestParam 由 RequestParamMethodArgumentResolver 處理RequestBody 由 RequestResponseBodyMethodProcessor 處理Model 類(lèi)型由 ModelMethodProcessor 處理。參數(shù)解析并不是單純從 request 里 getParameter 那么簡(jiǎn)單。類(lèi)型轉(zhuǎn)換才是核心難點(diǎn)。比如一個(gè)查詢(xún)參數(shù) age18目標(biāo)方法的參數(shù)類(lèi)型是 intSpring 會(huì)找到合適的轉(zhuǎn)換器把字符串轉(zhuǎn)為 Integer再比如前端傳一個(gè)日期字符串 2025-05-20目標(biāo)是 LocalDate就需要注冊(cè) DateTimeFormatter 才能正確轉(zhuǎn)換。如果轉(zhuǎn)換失敗框架拋出 TypeMismatchException最后會(huì)被異常解析器處理成 400 錯(cuò)誤。這里我說(shuō)一個(gè)很多人不重視但面試容易問(wèn)的點(diǎn)標(biāo)準(zhǔn) Servlet 規(guī)格里HTTP 請(qǐng)求參數(shù)和 multipart 文件上傳不是一回事。Spring 在處理文件上傳時(shí)需要配置 MultipartResolver。請(qǐng)求進(jìn)來(lái)后DispatcherServlet 會(huì)先調(diào)用 multipartResolver 的 isMultipart() 判斷請(qǐng)求是否包含文件如果包含就包裝成 MultipartHttpServletRequest。這個(gè)步驟發(fā)生在 doDispatch 調(diào)用 HandlerMapping 之前也就是說(shuō)文件上傳的請(qǐng)求在路由階段就已經(jīng)被特殊處理過(guò)了。在參數(shù)綁定的鏈路上還有兩個(gè)容易被忽略的細(xì)節(jié)。一是 Valid 注解的校驗(yàn)邏輯它在參數(shù)解析時(shí)通過(guò) DataBinder 完成校驗(yàn)結(jié)果會(huì)存到 BindingResult 里如果方法形參中有 BindingResult 參數(shù)Spring 會(huì)把校驗(yàn)錯(cuò)誤注入進(jìn)去而不是像無(wú)參綁定那樣直接拋異常。二是自定義參數(shù)解析器如果想要一個(gè)特殊對(duì)象比如當(dāng)前登錄用戶(hù)的信息可以在 WebMvcConfigurer 里添加自定義 HandlerMethodArgumentResolver這樣每個(gè) Controller 方法都能直接聲名一個(gè)參數(shù)來(lái)獲取登錄信息避免寫(xiě)一堆從 Session 取數(shù)據(jù)的重復(fù)代碼。參數(shù)綁定這一階段日常開(kāi)發(fā)里出問(wèn)題最多的就是日期格式、枚舉轉(zhuǎn)換、以及 JSON 對(duì)象反序列化。比如前端傳的日期是 “yyyy/MM/dd”后端默認(rèn)按 “yyyy-MM-dd” 解析就會(huì)拋 FormatException。解決方法是全局配置一個(gè)格式轉(zhuǎn)換器或者使用 JsonFormat 直接在實(shí)體類(lèi)字段上標(biāo)注格式。這塊建議在實(shí)際項(xiàng)目里統(tǒng)一約定時(shí)間格式別每個(gè)接口各搞一套不然維護(hù)成本很高。2.3 處理器調(diào)用與返回值處理參數(shù)準(zhǔn)備好了接下來(lái)就是真正執(zhí)行目標(biāo)方法。RequestMappingHandlerAdapter 的核心處理邏輯是從 HandlerExecutionChain 中提取出抬 headler 對(duì)象然后 invokeHandlerMethod。這里要先說(shuō)攔截器鏈在 DispatcherServlet 執(zhí)行 handler 之前會(huì)先調(diào)用 chain.applyPreHandle()也就是按順序執(zhí)行每個(gè)攔截器的 preHandle 方法。如果某個(gè)攔截器返回 false請(qǐng)求就中斷不再執(zhí)行后面的攔截器鏈和目標(biāo)方法直接走 afterCompletion 的清理邏輯。真正調(diào)用 handler 時(shí)RequestMappingHandlerAdapter 會(huì)創(chuàng)建 ServletInvocableHandlerMethod它負(fù)責(zé)把請(qǐng)求參數(shù)映射成方法參數(shù)再通過(guò)反射調(diào)用方法。Controller 方法執(zhí)行完返回值需要被處理成 ModelAndView 或響應(yīng)體。這里涉及 HandlerMethodReturnValueHandler。常見(jiàn)的返回值類(lèi)型包括 String邏輯視圖名、ModelAndView、View、Map、Model、ResponseBody 標(biāo)注的對(duì)象等。其中 ResponseBody 對(duì)象的處理由 RequestResponseBodyMethodProcessor 完成它會(huì)把對(duì)象交給 HttpMessageConverter 序列化成 JSON、XML 或其它格式。項(xiàng)目里常用 Jackson 做 JSON 序列化Spring Boot 默認(rèn)已經(jīng)自動(dòng)配置了 MappingJackson2HttpMessageConverter。需要自定義序列化規(guī)則時(shí)可以配置 ObjectMapper 的模塊比如對(duì)日期字段做全局序列化格式統(tǒng)一避免前端拿到一個(gè)末端帶數(shù)字的亂糟糟時(shí)間戳數(shù)組。再說(shuō)攔截器的執(zhí)行時(shí)機(jī)很多人說(shuō)“攔截器在 Controller 之前執(zhí)行”這話(huà)不完整。完整的順序是preHandle在 handler 執(zhí)行前按順序執(zhí)行所有攔截器如果有返回 false 則中斷、然后在 handler 執(zhí)行完成后執(zhí)行 postHandle此時(shí)已經(jīng)在目標(biāo)方法返回、正準(zhǔn)備渲染視圖之前、最后在完整請(qǐng)求處理完成后執(zhí)行 afterCompletion無(wú)論是否有異常都會(huì)執(zhí)行常用于釋放資源、清理上下文。這套順序在日常排查問(wèn)題時(shí)非常有用比如遇到“日志打了 preHandle 但業(yè)務(wù)方法沒(méi)執(zhí)行”的情況基本可以斷定是前面某個(gè)攔截器 preHandle 返回了 false或者拋了未處理異常。返回值處理這塊我建議大家在本地用日志或者斷點(diǎn)看一下實(shí)際返回路徑。說(shuō)個(gè)我看到的案例某同事在一個(gè) Controller 方法上同時(shí)寫(xiě)了 ResponseBody 和返回值 String一直以為返回的字符串會(huì)被解析成 JSON 字符串結(jié)果前端拿到的是帶引號(hào)的原始 JSON 格式。問(wèn)題就出在返回值解析器選擇邏輯ResponseBody 優(yōu)先走消息轉(zhuǎn)換器String 類(lèi)型會(huì)被 StringHttpMessageConverter 輸出原樣字符串并不會(huì)再次序列化成 JSON。這種細(xì)節(jié)看一遍源碼比背十篇博客有用。2.4 視圖解析與響應(yīng)輸出Spring MVC 的請(qǐng)求并不是都會(huì)走視圖解析。如果一個(gè)方法標(biāo)注了 ResponseBody或者返回的對(duì)象是 ResponseEntity框架會(huì)直接用消息轉(zhuǎn)換器寫(xiě)出響應(yīng)體不經(jīng)過(guò) ViewResolver。但如果方法返回的是邏輯視圖名String、View、ModelAndView那么 DispatcherServlet 就會(huì)調(diào)用 viewResolver 去解析出 View。這里再展開(kāi)講一下 ViewResolver 的解析流程DispatcherServlet 默認(rèn)使用 ViewResolver 列表中的第一個(gè)能返回 View 的解析器。InternalResourceViewResolver 是最常用的它會(huì)將邏輯視圖名拼接成服務(wù)器內(nèi)部資源路徑比如視圖名 “user/detail” 會(huì)被解析成 “/WEB-INF/views/user/detail.jsp”然后交給 RequestDispatcher 轉(zhuǎn)發(fā)到該資源。所以當(dāng) JSP 文件不存在時(shí)常見(jiàn)表現(xiàn)是 404因?yàn)閷?shí)際轉(zhuǎn)發(fā)到一個(gè)不存在的路徑。除了 JSP 還有 Thymeleaf、FreeMarker 等模板引擎它們也實(shí)現(xiàn)了 ViewResolver。使用 Thymeleaf 時(shí)需要配置 SpringTemplateEngine、模板解析器、視圖解析器Spring Boot 里加了依賴(lài)和配置項(xiàng)后自動(dòng)裝配省了很多事。不過(guò)要注意多個(gè)視圖解析器的順序比如同時(shí)存在 Thymeleaf 和 JSP 解析器順序不對(duì)可能導(dǎo)致視圖名被先解析成 JSP 路徑結(jié)果找不到文件。老項(xiàng)目里如果從 JSP 遷移到 Thymeleaf建議把 Thymeleaf 解析器的 order 設(shè)為更靠前的值并保留 JSP 解析器作為兼容。View 渲染的過(guò)程中也會(huì)涉及一步“隱藏”的操作那就是 HandlerExceptionResolver。如果 Controller 方法拋了異常DispatcherServlet 在 processDispatchResult 里會(huì)調(diào)用 processHandlerException逐個(gè)詢(xún)問(wèn)異常解析器誰(shuí)能處理當(dāng)前異常。ExceptionHandler 注解、ControllerAdvice 全局異常處理本質(zhì)上都注冊(cè)成了 ExceptionHandlerExceptionResolver。異常處理結(jié)果也可能返回 ModelAndView或者通過(guò) ResponseBody 直接輸出錯(cuò)誤 JSON。所以我一直強(qiáng)調(diào)把全局異常處理當(dāng)成請(qǐng)求流程的一環(huán)來(lái)理解而不是獨(dú)立的“裝飾性代碼”你會(huì)更容易定位很多線(xiàn)上問(wèn)題的根因。最終View 渲染的結(jié)果寫(xiě)入 HttpServletResponse。這中間涉及 response 的字符編碼、Content-Type、緩存控制頭等看似瑣碎但業(yè)務(wù)一旦出現(xiàn)亂碼、下載文件內(nèi)容損壞等問(wèn)題排查點(diǎn)往往就藏在響應(yīng)輸出這一步。比如用 StringHttpMessageConverter 輸出中文時(shí)默認(rèn)按 ISO-8859-1 編碼就會(huì)出現(xiàn)亂碼解決辦法通常是配置消息轉(zhuǎn)換器的默認(rèn)字符集為 UTF-8或者統(tǒng)一在 yml 里設(shè)置 server.servlet.encoding。很多新人踩這個(gè)坑花一天查代碼查不到原因其實(shí)問(wèn)題出在框架層默認(rèn)編碼。3. 手撕一個(gè)請(qǐng)求的完整旅程練一遍源碼級(jí)流程3.1 模擬場(chǎng)景與關(guān)鍵配置光講原理終究不如親手推一遍。下面用一個(gè)小場(chǎng)景把上面的流程串起來(lái)也方便你在本地跟著 Debug 過(guò)一遍。假設(shè)有一個(gè)簡(jiǎn)單的訂單接口Controller 定義如下RestController RequestMapping(/api/order) public class OrderController { GetMapping(/{id}) public Order queryOrder(PathVariable(id) Long id) { Order order new Order(); order.setId(id); order.setName(sample); return order; } }啟動(dòng)項(xiàng)目后瀏覽器訪(fǎng)問(wèn)GET http://localhost:8080/api/order/10086請(qǐng)求發(fā)出后我們按階段給每一步打上標(biāo)記然后對(duì)照 Spring MVC 源碼看整個(gè)過(guò)程。這里先給出一段配置確保項(xiàng)目是標(biāo)準(zhǔn)的 Spring Boot Web 工程沒(méi)有額外干擾因素spring: application: name: order-service web: resources: add-mappings: true server: port: 8080有人可能會(huì)覺(jué)得這個(gè)場(chǎng)景太簡(jiǎn)單沒(méi)有 JSP、沒(méi)有攔截器、沒(méi)有異常處理。實(shí)際上一個(gè)純 REST 接口反而更適合理解核心鏈路因?yàn)橐晥D解析和復(fù)雜參數(shù)解析都被簡(jiǎn)化了剩下的就是框架最基本的協(xié)作邏輯?；A(chǔ)鏈路搞清了再往復(fù)雜邊界上延伸會(huì)更輕松。3.2 核心階段追蹤階段一請(qǐng)求到達(dá) DispatcherServlet。容器將請(qǐng)求交給 DispatcherServlet 的 service 方法FrameworkServlet 將其轉(zhuǎn)為 processRequest。你在斷點(diǎn)里看到的第一個(gè)關(guān)鍵方法通常是 doService再往下是 doDispatch。doDispatch 第一件事就是檢查是否包含文件上傳請(qǐng)求這里沒(méi)有 multipart 文件直接跳過(guò)。接著遍歷 HandlerMappings 查找 handler。階段二HandlerMapping 匹配。RequestMappingHandlerMapping 解析到 /api/order/{id} 這個(gè)映射提取路徑變量 id 10086。同時(shí)會(huì)匹配 HTTP 方法 GET。如果請(qǐng)求路徑匹配了但方法不允許比如 POST 請(qǐng)求訪(fǎng)問(wèn)這個(gè) GET 接口框架會(huì)拋出 HttpRequestMethodNotSupportedException。這個(gè)細(xì)節(jié)容易被忽略HandlerMapping 返回 handler 成功不代表就可以執(zhí)行HTTP 方法也是映射條件的重要組成部分。階段三適配器執(zhí)行。HandlerAdapter 拿到 HandlerExecutionChain先生成一個(gè) HandlerMethodArgumentResolverComposite遍歷所有參數(shù)解析器找到 PathVariableMethodArgumentResolver 可處理參數(shù) id然后從 request 中提取路徑變量并轉(zhuǎn)換類(lèi)型反射調(diào)用 queryOrder 方法。調(diào)用前攔截器 chain.applyPreHandle 先執(zhí)行這里沒(méi)有配置攔截器直接放行。階段四返回值處理。queryOrder 返回一個(gè) Order 對(duì)象由于類(lèi)上是 RestController等價(jià)于類(lèi)和方法上都標(biāo)了 ResponseBody所以返回值處理器選擇 RequestResponseBodyMethodProcessor。它查找消息轉(zhuǎn)換器找到 MappingJackson2HttpMessageConverter把 Order 序列化成 JSON寫(xiě)入 Response。此時(shí)整個(gè)過(guò)程并沒(méi)有經(jīng)歷 ViewResolver 和 View 渲染。階段五收尾。DispatcherServlet 處理完成執(zhí)行 afterCompletion 清理釋放線(xiàn)程綁定的一些上下文資源響應(yīng)以 JSON 形式返回給瀏覽器。整個(gè)調(diào)用鏈從 doDispatch 到返回沒(méi)有出現(xiàn)視圖解析器。3.3 關(guān)鍵類(lèi)級(jí)邏輯對(duì)照我建議你本地打開(kāi) Spring 源碼將幾個(gè)關(guān)鍵類(lèi)打上斷點(diǎn)逐個(gè)看DispatcherServlet.doDispatch(HttpServletRequest request, HttpServletResponse response)RequestMappingHandlerMapping.lookupHandlerMethod(String lookupPath, HttpServletRequest request)RequestMappingHandlerAdapter.handleInternal(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod)ServletInvocableHandlerMethod.invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer, Object... provideArgs)如果你用的是 Spring Boot 3.x 或 2.7.x 等常用版本類(lèi)名基本都是一致的。逐個(gè)斷點(diǎn)走一遍后你會(huì)有一個(gè)很直觀(guān)的感受Spring MVC 把請(qǐng)求過(guò)程拆成了特別清晰的鏈?zhǔn)秸{(diào)用每個(gè)階段都是一段不太長(zhǎng)的代碼組合起來(lái)就形成了一個(gè)功能完備、擴(kuò)展點(diǎn)極多的大流程。多看幾遍源碼還有一個(gè)額外收獲你會(huì)發(fā)現(xiàn)在 doDispatch 中即使發(fā)生異?？蚣芤矔?huì)嘗試尋找異常處理器來(lái)處理而不是直接把異常拋給容器。這就是為什么 Controller 里拋異常前端能收到友好的 JSON 錯(cuò)誤提示而不是一堆堆棧信息。理解了這一點(diǎn)你就可以圍繞 HandlerExceptionResolver 做很多自定義工作比如統(tǒng)一響應(yīng)包裝結(jié)構(gòu)、錯(cuò)誤碼映射、日志埋點(diǎn)。我個(gè)人的建議是不要試圖一次看懂全部源碼。找一個(gè)最簡(jiǎn)單的 GET 請(qǐng)求把上面四個(gè)關(guān)鍵方法斷點(diǎn)打上來(lái)回看兩三遍然后試著關(guān)閉斷點(diǎn)自己畫(huà)一遍時(shí)序腦子里畫(huà)也行。等你畫(huà)到第 2 遍的時(shí)候會(huì)發(fā)現(xiàn)很多曾經(jīng)需要死記硬背的組件和順序已經(jīng)自然記住了。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 404 與映射失敗404 是 Spring MVC 開(kāi)發(fā)里出現(xiàn)概率最高的問(wèn)題但原因五花八門(mén)。最常見(jiàn)的有這么幾類(lèi)路徑明明寫(xiě)對(duì)了但請(qǐng)求進(jìn)入的上下文路徑不對(duì)導(dǎo)致 DispatcherServlet 根本沒(méi)接收到Controller 類(lèi)沒(méi)有加 RestController 或 Controller掃描不到方法上的 RequestMapping 路徑拼錯(cuò)了還有靜態(tài)資源被 DispatcherServlet 攔截URL 對(duì)應(yīng)不上任何 RequestMapping直接 404。排查這類(lèi)問(wèn)題我習(xí)慣先看后臺(tái)日志有沒(méi)有 DispatcherServlet 的接收痕跡。如果日志里根本沒(méi)有 Spring MVC 的請(qǐng)求處理記錄說(shuō)明DispatcherServlet 的映射路徑?jīng)]有覆蓋這個(gè)請(qǐng)求問(wèn)題出在 servlet 配置或攔截器上。如果有記錄但沒(méi)有匹配到 handler日志一般會(huì)輸出類(lèi)似 “No mapping for GET /api/xxx” 的提示?？吹竭@類(lèi)日志優(yōu)先去掃 Controller 類(lèi)的映射配置再檢查是不是 HandlerMapping 沒(méi)有掃描到相關(guān)包名。另外還有一個(gè)特別隱蔽的坑類(lèi)上用了 RequestMapping(/api)方法上又用了 GetMapping(/order/{id})但項(xiàng)目里某些路徑變量包含斜杠或特殊字符比如 id 本身是一個(gè)帶 / 的令牌值那么在路徑匹配時(shí)會(huì)因?yàn)闊o(wú)法正確拆分而 404。解決方式通常是改用 PathPattern 或調(diào)整路徑結(jié)構(gòu)如將參數(shù)放到 query string 而非路徑中。我在實(shí)際業(yè)務(wù)里遇到過(guò)接口參數(shù)里帶 URL 編碼后的斜杠修了很久才發(fā)現(xiàn)是路徑匹配和參數(shù)傳遞的邊界問(wèn)題。4.2 參數(shù)綁定與類(lèi)型轉(zhuǎn)換失敗參數(shù)綁定失敗通常是報(bào) 400 Bad Request消息里會(huì)提示是哪個(gè)參數(shù)無(wú)法匹配或轉(zhuǎn)換。比較典型的是前端傳了一個(gè)空字符串給 int 類(lèi)型字段或者把字符串 “a” 當(dāng)成 Long 類(lèi)型傳遞。Spring 的默認(rèn)類(lèi)型轉(zhuǎn)換器對(duì)這類(lèi)輸入沒(méi)有 AB 心理null 和空字符串轉(zhuǎn)基本類(lèi)型會(huì)有差異有時(shí)會(huì)轉(zhuǎn)成 0。這個(gè)行為在不同項(xiàng)目里可能不同因?yàn)?Spring Boot 對(duì) String 到 int 的處理有自己的策略但總體趨勢(shì)是如果轉(zhuǎn)換失敗會(huì)拋 TypeMismatchException。遇到參數(shù)綁定問(wèn)題我建議先看異常堆棧它會(huì)明確說(shuō)出是哪個(gè) converter 失敗以及原始值是什么。如果沒(méi)有明確提示可以在參數(shù)解析加斷點(diǎn)看看 HandlerMethodArgumentResolver 走到了哪個(gè)實(shí)現(xiàn)。很多時(shí)候問(wèn)題出在日期格式解決辦法是全局注冊(cè) ConverterString, LocalDate 或 DateTimeFormatterRegistrar。枚舉類(lèi)型也經(jīng)常出狀況前端傳的是枚舉名字后端枚舉定義的是中文 key 或數(shù)字 code就需要注冊(cè)一個(gè)自定義 Converter 來(lái)實(shí)現(xiàn)字符串到枚舉的映射。我還遇到過(guò)一個(gè)比較有意思的問(wèn)題同一個(gè) Controller 方法里參數(shù)名是 userId前端傳的也是 userId但注入后是 null。排查了半天發(fā)現(xiàn)是項(xiàng)目里開(kāi)啟了編譯參數(shù) -parameters 但 IDE 沒(méi)勾選保留參數(shù)名導(dǎo)致 Spring 只能通過(guò)反射獲取參數(shù)名拿到的是 arg0。Java 8 之后JDK 默認(rèn)不會(huì)在字節(jié)碼中保存方法參數(shù)名所以很多工程會(huì)用 -parameters 編譯選項(xiàng)。如果沒(méi)開(kāi)Spring 會(huì)退化成用注解或調(diào)試信息來(lái)解析。建議在 pom.xml 里顯式配置 -parameters同時(shí)配合 RequestParam、PathVariable 等注解明確名字避免這類(lèi)問(wèn)題。4.3 視圖渲染與響應(yīng)問(wèn)題這類(lèi)問(wèn)題主要出現(xiàn)在服務(wù)端渲染項(xiàng)目中。經(jīng)典癥狀是返回的視圖名正確頁(yè)面卻 404或者頁(yè)面渲染出來(lái)了但拿到模型數(shù)據(jù)是空還有一種更常見(jiàn)的用 Controller 沒(méi)有 ResponseBody返回 JSON結(jié)果得到的是視圖名對(duì)應(yīng)的頁(yè)面前端解析 JSON 時(shí)直接報(bào)錯(cuò)。排查視圖渲染 404建議第一步看 ViewResolver 的 prefix 和 suffix 是否配置正確。InternalResourceViewResolver 的 prefix 填錯(cuò)比如少了開(kāi)頭的斜杠或者目錄和真實(shí)結(jié)構(gòu)不一致就會(huì)轉(zhuǎn)發(fā)到一個(gè)不存在的路徑。第二步看 ViewResolver 的順序如果配置了多個(gè)解析器順序不對(duì)前面的解析器可能把視圖名當(dāng)成不可解析的邏輯名直接拋異常。第三步看模型數(shù)據(jù)是否在渲染時(shí)仍然有效比如用了重定向 redirect: 前綴模型數(shù)據(jù)如果不是用 RedirectAttributes 傳遞到下一次請(qǐng)求自然就丟失了。還有響應(yīng)亂碼這類(lèi)問(wèn)題在純 JSON 項(xiàng)目里不常見(jiàn)但在老 JSP 項(xiàng)目里很常見(jiàn)。亂碼一般源于編碼不一致請(qǐng)求本身是 UTF-8響應(yīng)卻按 ISO-8859-1 輸出。如果項(xiàng)目整體都是 UTF-8又出現(xiàn)部分接口亂碼往往是某個(gè)過(guò)濾器或攔截器在輸出響應(yīng)前改了字符編碼。還有一種情況是 ResponseBody 中文被轉(zhuǎn)碼成了 ? 號(hào)這個(gè)問(wèn)題多半是映射層的編碼配置不對(duì)。建議在配置中統(tǒng)一指定 server.servlet.encoding.forcetrue以及為 HttpMessageConverter 設(shè)置 UTF-8 字符集從根上解決。4.4 面試追問(wèn)備考清單既然題目是面試場(chǎng)景這里我把高頻追問(wèn)整理了一下。面試官不會(huì)只問(wèn)“流程是什么”更可能接著問(wèn)“為什么這里要這么做”“某個(gè)環(huán)節(jié)是否可替換”“出現(xiàn)異常如何流轉(zhuǎn)”。我把自己比較認(rèn)可的答法要點(diǎn)列一下為什么需要 HandlerAdapter直接把 Controller 方法拿來(lái)反射調(diào)用不行嗎 答因?yàn)?Spring MVC 的方法形態(tài)非常豐富RequestBody、PathVariable、Callable、StreamingResponseBody 等都需要不同的處理邏輯Adapter 把這些差異收束到統(tǒng)一的執(zhí)行接口上便于擴(kuò)展和維護(hù)。HandlerMapping 匹配失敗的是怎么處理的 答返回 null繼續(xù)下一個(gè) HandlerMapping。全部沒(méi)有匹配到時(shí)拋出 NoHandlerFoundException這個(gè)異常只有配置了 throwExceptionIfNoHandlerFound 時(shí)才會(huì)明確拋出否則可能直接返回 404 頁(yè)面。攔截器 preHandle 返回 false 之后會(huì)做什么 答不會(huì)繼續(xù)執(zhí)行后續(xù)攔截器和目標(biāo)方法但會(huì)執(zhí)行前面已經(jīng)創(chuàng)建好的攔截器的 afterCompletion 回調(diào)中已完成 preHandle 的部分。注意afterCompletion 里有 try-catch它主要用于清理資源。ControllerAdvice 和 HandlerExceptionResolver 的關(guān)系是什么 答ControllerAdvice 最終會(huì)注冊(cè)為 ExceptionHandlerExceptionResolver 的一個(gè)全局配置通過(guò)它可以把不同異常分發(fā)到對(duì)應(yīng)的方法處理并支持返回視圖或響應(yīng)體。異步請(qǐng)求 DeferredResult 和 Callable 在流程上有什么差別 答Callable 會(huì)讓 Spring MVC 把請(qǐng)求提交到任務(wù)執(zhí)行器異步計(jì)算DeferredResult 則允許業(yè)務(wù)線(xiàn)程自己決定何時(shí)設(shè)置結(jié)果。流程上都會(huì)從 DispatcherServlet 回歸到容器線(xiàn)程做響應(yīng)但中間會(huì)釋放 Tomcat 工作線(xiàn)程。ResponseBody 和 ResponseEntity 有什么區(qū)別 答ResponseBody 表示把返回值寫(xiě)進(jìn)響應(yīng)體ResponseEntity 可以同時(shí)控制 HTTP 狀態(tài)碼、響應(yīng)頭和響應(yīng)體。兩者在返回值處理器上走的是不同的處理器實(shí)現(xiàn)ResponseEntity 還要額外處理 header。這類(lèi)問(wèn)題答順了會(huì)讓面試官覺(jué)得不是死記硬背而是真正寫(xiě)過(guò)多輪請(qǐng)求鏈路代碼、排查過(guò)相關(guān)故障的人。我建議在回答時(shí)搭配一兩個(gè)自己真正調(diào)試過(guò)的小例子比如“我遇到過(guò) preHandle 返回 false 導(dǎo)致接口無(wú)響應(yīng)的問(wèn)題從日志里看到業(yè)務(wù)方法沒(méi)執(zhí)行一路排查才定位到攔截器邏輯”。這種細(xì)節(jié)比任何理論都有說(shuō)服力。最后再分享一個(gè)小技巧讀源碼時(shí)不要只看一個(gè)版本建議拿 Spring Framework 5.3.x 和 Spring Boot 2.7.x 的組合起步這套組合的源碼在本地加斷點(diǎn)非常順。等把 doDispatch 的路徑看熟了再去看 Spring Boot 3 基于 jakarta.servlet 的變化你會(huì)發(fā)現(xiàn)核心設(shè)計(jì)并沒(méi)有變變的只是包名和個(gè)別參數(shù)類(lèi)型。這也是面試時(shí)能自信說(shuō)“我基于源碼驗(yàn)證過(guò)”的基礎(chǔ)。 Spring MVC請(qǐng)求流程核心組件深入解析
1. 從一次請(qǐng)求說(shuō)起整體鏈路設(shè)計(jì)1.1 為什么需要一個(gè)統(tǒng)一前端控制器很多剛接觸 Java Web 的開(kāi)發(fā)者最早寫(xiě)的是 Servlet一個(gè)請(qǐng)求進(jìn)來(lái)根據(jù) URL 手動(dòng)判斷走哪個(gè)類(lèi)、調(diào)用哪個(gè)方法再到最后手動(dòng) setContentType、getWriter() 輸出 HTML。這種方式最大的問(wèn)題不在代碼量大而在“職責(zé)混亂”路由、參數(shù)解析、業(yè)務(wù)調(diào)用、響應(yīng)輸出全都揉在一個(gè)類(lèi)里改一個(gè) URL 規(guī)則就得動(dòng)業(yè)務(wù)代碼耦合高到讓人頭疼。Spring MVC 的出現(xiàn)本質(zhì)上就是想解決這個(gè)混亂。它把所有請(qǐng)求先交到一個(gè)統(tǒng)一入口——DispatcherServlet再去分發(fā)到具體的業(yè)務(wù)方法。這就是“前端控制器”模式。其實(shí)同類(lèi)型的思想在很多框架里都能看到比如 Struts、JSF 里也有類(lèi)似的集中分發(fā)組件但 Spring MVC 把這件事做得更干凈組件拆得更細(xì)擴(kuò)展點(diǎn)也更多。面試中如果被問(wèn)到“Spring MVC 請(qǐng)求流程”大概率不是想聽(tīng)你背幾個(gè)類(lèi)的名字而是想確認(rèn)你是否清楚一條請(qǐng)求從瀏覽器發(fā)起到響應(yīng)返回中間被拆成了哪些階段、每個(gè)階段由誰(shuí)負(fù)責(zé)、哪個(gè)環(huán)節(jié)是固定流程、哪個(gè)環(huán)節(jié)可以靈活擴(kuò)展。把這些回答透了比單純背出 DispatcherServlet、HandlerMapping、HandlerAdapter 這幾個(gè)單詞要有說(shuō)服力得多。1.2 請(qǐng)求流程的核心鏈路總覽先給一個(gè)最簡(jiǎn)版的總覽方便后面逐層展開(kāi)。一個(gè)標(biāo)準(zhǔn) Spring MVC 請(qǐng)求大致會(huì)經(jīng)過(guò)下面幾個(gè)階段請(qǐng)求到達(dá) DispatcherServlet框架拿到 HttpServletRequest 和 HttpServletResponse。DispatcherServlet 調(diào)用 HandlerMapping根據(jù)請(qǐng)求路徑、請(qǐng)求方法等條件找到能處理這個(gè)請(qǐng)求的 Handler通常是一個(gè) Controller 方法。DispatcherServlet 調(diào)用 HandlerAdapter 去執(zhí)行這個(gè) Handler。在執(zhí)行前后還可能經(jīng)過(guò)攔截器鏈Interceptor Chain。Controller 方法執(zhí)行業(yè)務(wù)邏輯返回一個(gè) ModelAndView或者使用 ResponseBody 直接寫(xiě)出響應(yīng)體。DispatcherServlet 把結(jié)果交給 ViewResolver 解析得到 View 對(duì)象并渲染輸出如果走的是 JSON 等消息轉(zhuǎn)換則由 HttpMessageConverter 完成輸出。簡(jiǎn)單理解DispatcherServlet 就像公司前臺(tái)它不干具體業(yè)務(wù)只負(fù)責(zé)接待、分配、協(xié)調(diào)資源HandlerMapping 相當(dāng)于內(nèi)部通訊錄負(fù)責(zé)查哪個(gè)部門(mén)來(lái)辦這件事HandlerAdapter 相當(dāng)于部門(mén)里具體干活的人不同的 Controller 方法形態(tài)需要不同的執(zhí)行方式ViewResolver 則像排版師傅負(fù)責(zé)把結(jié)果整理成客戶(hù)看得懂的樣子。這個(gè)流程用大白話(huà)說(shuō)并不難難的是把幾個(gè)關(guān)鍵組件之間的協(xié)作和邊界說(shuō)清。很多開(kāi)發(fā)者能說(shuō)出大概鏈條但不能解釋 HandlerAdapter 為什么要存在或者說(shuō)不出攔截器到底在哪個(gè)階段執(zhí)行。這些細(xì)節(jié)才是面試官區(qū)分你“背過(guò)答案”和“真懂原理”的關(guān)鍵點(diǎn)。1.3 請(qǐng)求流程的組件職責(zé)劃分先把核心組件的職責(zé)講透后面才能順暢地看源碼和實(shí)操。DispatcherServlet 是 Spring MVC 的門(mén)面它繼承自 FrameworkServlet再往上繼承 HttpServletBean 和 HttpServlet。它在初始化時(shí)會(huì)收集 WebApplicationContext 中所有相關(guān)組件包括 HandlerMapping、HandlerAdapter、ViewResolver、LocaleResolver、ThemeResolver、HandlerExceptionResolver 等并在 doDispatch 中把它們組合起來(lái)完成一次請(qǐng)求處理。HandlerMapping 負(fù)責(zé)“請(qǐng)求到方法的映射”。最常見(jiàn)的是 RequestMappingHandlerMapping它掃描 RequestMapping 注解把請(qǐng)求路徑、HTTP 方法、參數(shù)條件等內(nèi)容映射到 Controller 的 Method并緩存起來(lái)。匹配時(shí)需要處理路徑變量、通配符、produces/consumes 條件等。Spring 會(huì)持有多個(gè) HandlerMapping按順序逐個(gè)嘗試拿到第一個(gè)能處理的就返回。HandlerAdapter 負(fù)責(zé)“調(diào)用真正的處理邏輯”。有人會(huì)問(wèn)既然 Handler 都已經(jīng)找到 Controller 方法了為什么不直接反射調(diào)用還要再套一層適配器原因是 Controller 方法的定義方式太靈活了可能是普通的無(wú)參方法可能帶 RequestBody 參數(shù)可能返回 String、ModelAndView、ResponseEntity也可能是 Callable 或 DeferredResult 異步返回。Adapter 的作用就是把不同的方法形態(tài)統(tǒng)一適配成 ModelAndView 或 ResponseBody 結(jié)果。RequestMappingHandlerAdapter 是核心實(shí)現(xiàn)它內(nèi)部會(huì)處理參數(shù)解析器和返回值處理器。ViewResolver 負(fù)責(zé)把邏輯視圖名解析成具體的 View。常見(jiàn)的有 InternalResourceViewResolver它把 “user/list” 拼接成 “/WEB-INF/views/user/list.jsp” 這樣的真實(shí)路徑。還有 Thymeleaf 的視圖解析器、FreeMarker 的視圖解析器等。View 對(duì)象拿到模型數(shù)據(jù)后做模板渲染然后輸出到 Response。這四類(lèi)組件是 Spring MVC 的核心骨架。理解它們之間的層次關(guān)系再去看請(qǐng)求流程就不會(huì)糊。下面的章節(jié)我會(huì)逐階段拆流程把配置、源碼、實(shí)操、踩坑揉在一起講。2. 請(qǐng)求流程各階段細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 請(qǐng)求到達(dá)與處理器映射先看請(qǐng)求進(jìn)來(lái)那一刻發(fā)生了什么。容器在 web.xml 或通過(guò) Servlet 注解把 DispatcherServlet 映射到 “/” 路徑所以所有請(qǐng)求都會(huì)先落到它的 service 方法。FrameworkServlet 重寫(xiě)了 service()把 GET、POST、PUT、DELETE 等請(qǐng)求統(tǒng)一交給 processRequest() 處理。processRequest 里做幾件重要的事設(shè)置 LocaleContext、裝配 RequestAttributes、注冊(cè)可銷(xiāo)毀回調(diào)然后調(diào)用 doService()最后恢復(fù)現(xiàn)場(chǎng)。這里有個(gè)容易被忽視的細(xì)節(jié)請(qǐng)求參數(shù)、Locale 等上下文會(huì)被綁定到當(dāng)前線(xiàn)程方便后續(xù)代碼通過(guò) RequestContextHolder 訪(fǎng)問(wèn)。接下來(lái)進(jìn)入 DispatcherServlet 的 doService()。它把一些常用屬性塞進(jìn) request 的 attribute 中比如 webApplicationContext、localeResolver、themeResolver 等然后調(diào)用 doDispatch()。doDispatch 是整個(gè)流程的核心幾乎所有關(guān)鍵組件的調(diào)用都發(fā)生在這里。從這一層開(kāi)始你才能在源碼里真正看清 HandlerMapping 和 HandlerAdapter 是如何協(xié)作的。HandlerMapping 大多數(shù)項(xiàng)目里只有一個(gè) RequestMappingHandlerMapping但在復(fù)雜工程中可能有多個(gè)。Spring 會(huì)維護(hù)一個(gè)按 order 排序的列表依次調(diào)用 getHandler(request) 方法拿到第一個(gè)非空結(jié)果就用。getHandler 內(nèi)部會(huì)讓每個(gè) HandlerMapping 去計(jì)算 handler 和攔截器鏈最后返回一個(gè) HandlerExecutionChain。注意HandlerExecutionChain 里除了 handler 本身還包含匹配到的所有 HandlerInterceptor。HandMapping 匹配時(shí)需要處理路徑變量提取、正則表達(dá)式匹配、consumes 與 produces 條件判斷。比如 RequestMapping(value /api/user/{id}, method RequestMethod.GET, produces application/json)那么請(qǐng)求路徑 /api/user/123 且 Accept 頭包含 application/json 時(shí)才能命中。處理失敗則返回 null繼續(xù)下一個(gè)映射器。實(shí)操中比較常見(jiàn)的坑是路徑匹配規(guī)則和靜態(tài)資源沖突。很多項(xiàng)目在配置 DispatcherServlet 時(shí)映射到 “/”導(dǎo)致靜態(tài)資源 JS/CSS 也被當(dāng)成動(dòng)態(tài)請(qǐng)求處理出現(xiàn) 404。解決辦法是使用 mvc:resources 或 WebMvcConfigurer 中的 addResourceHandlers 顯式聲明靜態(tài)資源映射讓默認(rèn) Servlet 處理。另一個(gè)坑是 URL 大小寫(xiě)問(wèn)題Spring 默認(rèn)區(qū)分大小寫(xiě)如果你在 Linux 上部署把 /Api/User 寫(xiě)成 /api/user 就會(huì)匹配失敗但本地 Windows 又發(fā)現(xiàn)沒(méi)問(wèn)題容易讓人摸不著頭腦。2.2 參數(shù)綁定與類(lèi)型轉(zhuǎn)換在 HandlerMapping 找到目標(biāo)方法之后真正調(diào)用方法之前需要先解決一個(gè)問(wèn)題方法的參數(shù)從哪里來(lái)Spring MVC 在這兒設(shè)計(jì)了一套非常靈活的機(jī)制那就是 HandlerMethodArgumentResolver。每一種參數(shù)類(lèi)型都可以有對(duì)應(yīng)的解析器比如 PathVariable 由 PathVariableMethodArgumentResolver 處理RequestParam 由 RequestParamMethodArgumentResolver 處理RequestBody 由 RequestResponseBodyMethodProcessor 處理Model 類(lèi)型由 ModelMethodProcessor 處理。參數(shù)解析并不是單純從 request 里 getParameter 那么簡(jiǎn)單。類(lèi)型轉(zhuǎn)換才是核心難點(diǎn)。比如一個(gè)查詢(xún)參數(shù) age18目標(biāo)方法的參數(shù)類(lèi)型是 intSpring 會(huì)找到合適的轉(zhuǎn)換器把字符串轉(zhuǎn)為 Integer再比如前端傳一個(gè)日期字符串 2025-05-20目標(biāo)是 LocalDate就需要注冊(cè) DateTimeFormatter 才能正確轉(zhuǎn)換。如果轉(zhuǎn)換失敗框架拋出 TypeMismatchException最后會(huì)被異常解析器處理成 400 錯(cuò)誤。這里我說(shuō)一個(gè)很多人不重視但面試容易問(wèn)的點(diǎn)標(biāo)準(zhǔn) Servlet 規(guī)格里HTTP 請(qǐng)求參數(shù)和 multipart 文件上傳不是一回事。Spring 在處理文件上傳時(shí)需要配置 MultipartResolver。請(qǐng)求進(jìn)來(lái)后DispatcherServlet 會(huì)先調(diào)用 multipartResolver 的 isMultipart() 判斷請(qǐng)求是否包含文件如果包含就包裝成 MultipartHttpServletRequest。這個(gè)步驟發(fā)生在 doDispatch 調(diào)用 HandlerMapping 之前也就是說(shuō)文件上傳的請(qǐng)求在路由階段就已經(jīng)被特殊處理過(guò)了。在參數(shù)綁定的鏈路上還有兩個(gè)容易被忽略的細(xì)節(jié)。一是 Valid 注解的校驗(yàn)邏輯它在參數(shù)解析時(shí)通過(guò) DataBinder 完成校驗(yàn)結(jié)果會(huì)存到 BindingResult 里如果方法形參中有 BindingResult 參數(shù)Spring 會(huì)把校驗(yàn)錯(cuò)誤注入進(jìn)去而不是像無(wú)參綁定那樣直接拋異常。二是自定義參數(shù)解析器如果想要一個(gè)特殊對(duì)象比如當(dāng)前登錄用戶(hù)的信息可以在 WebMvcConfigurer 里添加自定義 HandlerMethodArgumentResolver這樣每個(gè) Controller 方法都能直接聲名一個(gè)參數(shù)來(lái)獲取登錄信息避免寫(xiě)一堆從 Session 取數(shù)據(jù)的重復(fù)代碼。參數(shù)綁定這一階段日常開(kāi)發(fā)里出問(wèn)題最多的就是日期格式、枚舉轉(zhuǎn)換、以及 JSON 對(duì)象反序列化。比如前端傳的日期是 “yyyy/MM/dd”后端默認(rèn)按 “yyyy-MM-dd” 解析就會(huì)拋 FormatException。解決方法是全局配置一個(gè)格式轉(zhuǎn)換器或者使用 JsonFormat 直接在實(shí)體類(lèi)字段上標(biāo)注格式。這塊建議在實(shí)際項(xiàng)目里統(tǒng)一約定時(shí)間格式別每個(gè)接口各搞一套不然維護(hù)成本很高。2.3 處理器調(diào)用與返回值處理參數(shù)準(zhǔn)備好了接下來(lái)就是真正執(zhí)行目標(biāo)方法。RequestMappingHandlerAdapter 的核心處理邏輯是從 HandlerExecutionChain 中提取出抬 headler 對(duì)象然后 invokeHandlerMethod。這里要先說(shuō)攔截器鏈在 DispatcherServlet 執(zhí)行 handler 之前會(huì)先調(diào)用 chain.applyPreHandle()也就是按順序執(zhí)行每個(gè)攔截器的 preHandle 方法。如果某個(gè)攔截器返回 false請(qǐng)求就中斷不再執(zhí)行后面的攔截器鏈和目標(biāo)方法直接走 afterCompletion 的清理邏輯。真正調(diào)用 handler 時(shí)RequestMappingHandlerAdapter 會(huì)創(chuàng)建 ServletInvocableHandlerMethod它負(fù)責(zé)把請(qǐng)求參數(shù)映射成方法參數(shù)再通過(guò)反射調(diào)用方法。Controller 方法執(zhí)行完返回值需要被處理成 ModelAndView 或響應(yīng)體。這里涉及 HandlerMethodReturnValueHandler。常見(jiàn)的返回值類(lèi)型包括 String邏輯視圖名、ModelAndView、View、Map、Model、ResponseBody 標(biāo)注的對(duì)象等。其中 ResponseBody 對(duì)象的處理由 RequestResponseBodyMethodProcessor 完成它會(huì)把對(duì)象交給 HttpMessageConverter 序列化成 JSON、XML 或其它格式。項(xiàng)目里常用 Jackson 做 JSON 序列化Spring Boot 默認(rèn)已經(jīng)自動(dòng)配置了 MappingJackson2HttpMessageConverter。需要自定義序列化規(guī)則時(shí)可以配置 ObjectMapper 的模塊比如對(duì)日期字段做全局序列化格式統(tǒng)一避免前端拿到一個(gè)末端帶數(shù)字的亂糟糟時(shí)間戳數(shù)組。再說(shuō)攔截器的執(zhí)行時(shí)機(jī)很多人說(shuō)“攔截器在 Controller 之前執(zhí)行”這話(huà)不完整。完整的順序是preHandle在 handler 執(zhí)行前按順序執(zhí)行所有攔截器如果有返回 false 則中斷、然后在 handler 執(zhí)行完成后執(zhí)行 postHandle此時(shí)已經(jīng)在目標(biāo)方法返回、正準(zhǔn)備渲染視圖之前、最后在完整請(qǐng)求處理完成后執(zhí)行 afterCompletion無(wú)論是否有異常都會(huì)執(zhí)行常用于釋放資源、清理上下文。這套順序在日常排查問(wèn)題時(shí)非常有用比如遇到“日志打了 preHandle 但業(yè)務(wù)方法沒(méi)執(zhí)行”的情況基本可以斷定是前面某個(gè)攔截器 preHandle 返回了 false或者拋了未處理異常。返回值處理這塊我建議大家在本地用日志或者斷點(diǎn)看一下實(shí)際返回路徑。說(shuō)個(gè)我看到的案例某同事在一個(gè) Controller 方法上同時(shí)寫(xiě)了 ResponseBody 和返回值 String一直以為返回的字符串會(huì)被解析成 JSON 字符串結(jié)果前端拿到的是帶引號(hào)的原始 JSON 格式。問(wèn)題就出在返回值解析器選擇邏輯ResponseBody 優(yōu)先走消息轉(zhuǎn)換器String 類(lèi)型會(huì)被 StringHttpMessageConverter 輸出原樣字符串并不會(huì)再次序列化成 JSON。這種細(xì)節(jié)看一遍源碼比背十篇博客有用。2.4 視圖解析與響應(yīng)輸出Spring MVC 的請(qǐng)求并不是都會(huì)走視圖解析。如果一個(gè)方法標(biāo)注了 ResponseBody或者返回的對(duì)象是 ResponseEntity框架會(huì)直接用消息轉(zhuǎn)換器寫(xiě)出響應(yīng)體不經(jīng)過(guò) ViewResolver。但如果方法返回的是邏輯視圖名String、View、ModelAndView那么 DispatcherServlet 就會(huì)調(diào)用 viewResolver 去解析出 View。這里再展開(kāi)講一下 ViewResolver 的解析流程DispatcherServlet 默認(rèn)使用 ViewResolver 列表中的第一個(gè)能返回 View 的解析器。InternalResourceViewResolver 是最常用的它會(huì)將邏輯視圖名拼接成服務(wù)器內(nèi)部資源路徑比如視圖名 “user/detail” 會(huì)被解析成 “/WEB-INF/views/user/detail.jsp”然后交給 RequestDispatcher 轉(zhuǎn)發(fā)到該資源。所以當(dāng) JSP 文件不存在時(shí)常見(jiàn)表現(xiàn)是 404因?yàn)閷?shí)際轉(zhuǎn)發(fā)到一個(gè)不存在的路徑。除了 JSP 還有 Thymeleaf、FreeMarker 等模板引擎它們也實(shí)現(xiàn)了 ViewResolver。使用 Thymeleaf 時(shí)需要配置 SpringTemplateEngine、模板解析器、視圖解析器Spring Boot 里加了依賴(lài)和配置項(xiàng)后自動(dòng)裝配省了很多事。不過(guò)要注意多個(gè)視圖解析器的順序比如同時(shí)存在 Thymeleaf 和 JSP 解析器順序不對(duì)可能導(dǎo)致視圖名被先解析成 JSP 路徑結(jié)果找不到文件。老項(xiàng)目里如果從 JSP 遷移到 Thymeleaf建議把 Thymeleaf 解析器的 order 設(shè)為更靠前的值并保留 JSP 解析器作為兼容。View 渲染的過(guò)程中也會(huì)涉及一步“隱藏”的操作那就是 HandlerExceptionResolver。如果 Controller 方法拋了異常DispatcherServlet 在 processDispatchResult 里會(huì)調(diào)用 processHandlerException逐個(gè)詢(xún)問(wèn)異常解析器誰(shuí)能處理當(dāng)前異常。ExceptionHandler 注解、ControllerAdvice 全局異常處理本質(zhì)上都注冊(cè)成了 ExceptionHandlerExceptionResolver。異常處理結(jié)果也可能返回 ModelAndView或者通過(guò) ResponseBody 直接輸出錯(cuò)誤 JSON。所以我一直強(qiáng)調(diào)把全局異常處理當(dāng)成請(qǐng)求流程的一環(huán)來(lái)理解而不是獨(dú)立的“裝飾性代碼”你會(huì)更容易定位很多線(xiàn)上問(wèn)題的根因。最終View 渲染的結(jié)果寫(xiě)入 HttpServletResponse。這中間涉及 response 的字符編碼、Content-Type、緩存控制頭等看似瑣碎但業(yè)務(wù)一旦出現(xiàn)亂碼、下載文件內(nèi)容損壞等問(wèn)題排查點(diǎn)往往就藏在響應(yīng)輸出這一步。比如用 StringHttpMessageConverter 輸出中文時(shí)默認(rèn)按 ISO-8859-1 編碼就會(huì)出現(xiàn)亂碼解決辦法通常是配置消息轉(zhuǎn)換器的默認(rèn)字符集為 UTF-8或者統(tǒng)一在 yml 里設(shè)置 server.servlet.encoding。很多新人踩這個(gè)坑花一天查代碼查不到原因其實(shí)問(wèn)題出在框架層默認(rèn)編碼。3. 手撕一個(gè)請(qǐng)求的完整旅程練一遍源碼級(jí)流程3.1 模擬場(chǎng)景與關(guān)鍵配置光講原理終究不如親手推一遍。下面用一個(gè)小場(chǎng)景把上面的流程串起來(lái)也方便你在本地跟著 Debug 過(guò)一遍。假設(shè)有一個(gè)簡(jiǎn)單的訂單接口Controller 定義如下RestController RequestMapping(/api/order) public class OrderController { GetMapping(/{id}) public Order queryOrder(PathVariable(id) Long id) { Order order new Order(); order.setId(id); order.setName(sample); return order; } }啟動(dòng)項(xiàng)目后瀏覽器訪(fǎng)問(wèn)GET http://localhost:8080/api/order/10086請(qǐng)求發(fā)出后我們按階段給每一步打上標(biāo)記然后對(duì)照 Spring MVC 源碼看整個(gè)過(guò)程。這里先給出一段配置確保項(xiàng)目是標(biāo)準(zhǔn)的 Spring Boot Web 工程沒(méi)有額外干擾因素spring: application: name: order-service web: resources: add-mappings: true server: port: 8080有人可能會(huì)覺(jué)得這個(gè)場(chǎng)景太簡(jiǎn)單沒(méi)有 JSP、沒(méi)有攔截器、沒(méi)有異常處理。實(shí)際上一個(gè)純 REST 接口反而更適合理解核心鏈路因?yàn)橐晥D解析和復(fù)雜參數(shù)解析都被簡(jiǎn)化了剩下的就是框架最基本的協(xié)作邏輯?；A(chǔ)鏈路搞清了再往復(fù)雜邊界上延伸會(huì)更輕松。3.2 核心階段追蹤階段一請(qǐng)求到達(dá) DispatcherServlet。容器將請(qǐng)求交給 DispatcherServlet 的 service 方法FrameworkServlet 將其轉(zhuǎn)為 processRequest。你在斷點(diǎn)里看到的第一個(gè)關(guān)鍵方法通常是 doService再往下是 doDispatch。doDispatch 第一件事就是檢查是否包含文件上傳請(qǐng)求這里沒(méi)有 multipart 文件直接跳過(guò)。接著遍歷 HandlerMappings 查找 handler。階段二HandlerMapping 匹配。RequestMappingHandlerMapping 解析到 /api/order/{id} 這個(gè)映射提取路徑變量 id 10086。同時(shí)會(huì)匹配 HTTP 方法 GET。如果請(qǐng)求路徑匹配了但方法不允許比如 POST 請(qǐng)求訪(fǎng)問(wèn)這個(gè) GET 接口框架會(huì)拋出 HttpRequestMethodNotSupportedException。這個(gè)細(xì)節(jié)容易被忽略HandlerMapping 返回 handler 成功不代表就可以執(zhí)行HTTP 方法也是映射條件的重要組成部分。階段三適配器執(zhí)行。HandlerAdapter 拿到 HandlerExecutionChain先生成一個(gè) HandlerMethodArgumentResolverComposite遍歷所有參數(shù)解析器找到 PathVariableMethodArgumentResolver 可處理參數(shù) id然后從 request 中提取路徑變量并轉(zhuǎn)換類(lèi)型反射調(diào)用 queryOrder 方法。調(diào)用前攔截器 chain.applyPreHandle 先執(zhí)行這里沒(méi)有配置攔截器直接放行。階段四返回值處理。queryOrder 返回一個(gè) Order 對(duì)象由于類(lèi)上是 RestController等價(jià)于類(lèi)和方法上都標(biāo)了 ResponseBody所以返回值處理器選擇 RequestResponseBodyMethodProcessor。它查找消息轉(zhuǎn)換器找到 MappingJackson2HttpMessageConverter把 Order 序列化成 JSON寫(xiě)入 Response。此時(shí)整個(gè)過(guò)程并沒(méi)有經(jīng)歷 ViewResolver 和 View 渲染。階段五收尾。DispatcherServlet 處理完成執(zhí)行 afterCompletion 清理釋放線(xiàn)程綁定的一些上下文資源響應(yīng)以 JSON 形式返回給瀏覽器。整個(gè)調(diào)用鏈從 doDispatch 到返回沒(méi)有出現(xiàn)視圖解析器。3.3 關(guān)鍵類(lèi)級(jí)邏輯對(duì)照我建議你本地打開(kāi) Spring 源碼將幾個(gè)關(guān)鍵類(lèi)打上斷點(diǎn)逐個(gè)看DispatcherServlet.doDispatch(HttpServletRequest request, HttpServletResponse response)RequestMappingHandlerMapping.lookupHandlerMethod(String lookupPath, HttpServletRequest request)RequestMappingHandlerAdapter.handleInternal(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod)ServletInvocableHandlerMethod.invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer, Object... provideArgs)如果你用的是 Spring Boot 3.x 或 2.7.x 等常用版本類(lèi)名基本都是一致的。逐個(gè)斷點(diǎn)走一遍后你會(huì)有一個(gè)很直觀(guān)的感受Spring MVC 把請(qǐng)求過(guò)程拆成了特別清晰的鏈?zhǔn)秸{(diào)用每個(gè)階段都是一段不太長(zhǎng)的代碼組合起來(lái)就形成了一個(gè)功能完備、擴(kuò)展點(diǎn)極多的大流程。多看幾遍源碼還有一個(gè)額外收獲你會(huì)發(fā)現(xiàn)在 doDispatch 中即使發(fā)生異?？蚣芤矔?huì)嘗試尋找異常處理器來(lái)處理而不是直接把異常拋給容器。這就是為什么 Controller 里拋異常前端能收到友好的 JSON 錯(cuò)誤提示而不是一堆堆棧信息。理解了這一點(diǎn)你就可以圍繞 HandlerExceptionResolver 做很多自定義工作比如統(tǒng)一響應(yīng)包裝結(jié)構(gòu)、錯(cuò)誤碼映射、日志埋點(diǎn)。我個(gè)人的建議是不要試圖一次看懂全部源碼。找一個(gè)最簡(jiǎn)單的 GET 請(qǐng)求把上面四個(gè)關(guān)鍵方法斷點(diǎn)打上來(lái)回看兩三遍然后試著關(guān)閉斷點(diǎn)自己畫(huà)一遍時(shí)序腦子里畫(huà)也行。等你畫(huà)到第 2 遍的時(shí)候會(huì)發(fā)現(xiàn)很多曾經(jīng)需要死記硬背的組件和順序已經(jīng)自然記住了。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 404 與映射失敗404 是 Spring MVC 開(kāi)發(fā)里出現(xiàn)概率最高的問(wèn)題但原因五花八門(mén)。最常見(jiàn)的有這么幾類(lèi)路徑明明寫(xiě)對(duì)了但請(qǐng)求進(jìn)入的上下文路徑不對(duì)導(dǎo)致 DispatcherServlet 根本沒(méi)接收到Controller 類(lèi)沒(méi)有加 RestController 或 Controller掃描不到方法上的 RequestMapping 路徑拼錯(cuò)了還有靜態(tài)資源被 DispatcherServlet 攔截URL 對(duì)應(yīng)不上任何 RequestMapping直接 404。排查這類(lèi)問(wèn)題我習(xí)慣先看后臺(tái)日志有沒(méi)有 DispatcherServlet 的接收痕跡。如果日志里根本沒(méi)有 Spring MVC 的請(qǐng)求處理記錄說(shuō)明DispatcherServlet 的映射路徑?jīng)]有覆蓋這個(gè)請(qǐng)求問(wèn)題出在 servlet 配置或攔截器上。如果有記錄但沒(méi)有匹配到 handler日志一般會(huì)輸出類(lèi)似 “No mapping for GET /api/xxx” 的提示?？吹竭@類(lèi)日志優(yōu)先去掃 Controller 類(lèi)的映射配置再檢查是不是 HandlerMapping 沒(méi)有掃描到相關(guān)包名。另外還有一個(gè)特別隱蔽的坑類(lèi)上用了 RequestMapping(/api)方法上又用了 GetMapping(/order/{id})但項(xiàng)目里某些路徑變量包含斜杠或特殊字符比如 id 本身是一個(gè)帶 / 的令牌值那么在路徑匹配時(shí)會(huì)因?yàn)闊o(wú)法正確拆分而 404。解決方式通常是改用 PathPattern 或調(diào)整路徑結(jié)構(gòu)如將參數(shù)放到 query string 而非路徑中。我在實(shí)際業(yè)務(wù)里遇到過(guò)接口參數(shù)里帶 URL 編碼后的斜杠修了很久才發(fā)現(xiàn)是路徑匹配和參數(shù)傳遞的邊界問(wèn)題。4.2 參數(shù)綁定與類(lèi)型轉(zhuǎn)換失敗參數(shù)綁定失敗通常是報(bào) 400 Bad Request消息里會(huì)提示是哪個(gè)參數(shù)無(wú)法匹配或轉(zhuǎn)換。比較典型的是前端傳了一個(gè)空字符串給 int 類(lèi)型字段或者把字符串 “a” 當(dāng)成 Long 類(lèi)型傳遞。Spring 的默認(rèn)類(lèi)型轉(zhuǎn)換器對(duì)這類(lèi)輸入沒(méi)有 AB 心理null 和空字符串轉(zhuǎn)基本類(lèi)型會(huì)有差異有時(shí)會(huì)轉(zhuǎn)成 0。這個(gè)行為在不同項(xiàng)目里可能不同因?yàn)?Spring Boot 對(duì) String 到 int 的處理有自己的策略但總體趨勢(shì)是如果轉(zhuǎn)換失敗會(huì)拋 TypeMismatchException。遇到參數(shù)綁定問(wèn)題我建議先看異常堆棧它會(huì)明確說(shuō)出是哪個(gè) converter 失敗以及原始值是什么。如果沒(méi)有明確提示可以在參數(shù)解析加斷點(diǎn)看看 HandlerMethodArgumentResolver 走到了哪個(gè)實(shí)現(xiàn)。很多時(shí)候問(wèn)題出在日期格式解決辦法是全局注冊(cè) ConverterString, LocalDate 或 DateTimeFormatterRegistrar。枚舉類(lèi)型也經(jīng)常出狀況前端傳的是枚舉名字后端枚舉定義的是中文 key 或數(shù)字 code就需要注冊(cè)一個(gè)自定義 Converter 來(lái)實(shí)現(xiàn)字符串到枚舉的映射。我還遇到過(guò)一個(gè)比較有意思的問(wèn)題同一個(gè) Controller 方法里參數(shù)名是 userId前端傳的也是 userId但注入后是 null。排查了半天發(fā)現(xiàn)是項(xiàng)目里開(kāi)啟了編譯參數(shù) -parameters 但 IDE 沒(méi)勾選保留參數(shù)名導(dǎo)致 Spring 只能通過(guò)反射獲取參數(shù)名拿到的是 arg0。Java 8 之后JDK 默認(rèn)不會(huì)在字節(jié)碼中保存方法參數(shù)名所以很多工程會(huì)用 -parameters 編譯選項(xiàng)。如果沒(méi)開(kāi)Spring 會(huì)退化成用注解或調(diào)試信息來(lái)解析。建議在 pom.xml 里顯式配置 -parameters同時(shí)配合 RequestParam、PathVariable 等注解明確名字避免這類(lèi)問(wèn)題。4.3 視圖渲染與響應(yīng)問(wèn)題這類(lèi)問(wèn)題主要出現(xiàn)在服務(wù)端渲染項(xiàng)目中。經(jīng)典癥狀是返回的視圖名正確頁(yè)面卻 404或者頁(yè)面渲染出來(lái)了但拿到模型數(shù)據(jù)是空還有一種更常見(jiàn)的用 Controller 沒(méi)有 ResponseBody返回 JSON結(jié)果得到的是視圖名對(duì)應(yīng)的頁(yè)面前端解析 JSON 時(shí)直接報(bào)錯(cuò)。排查視圖渲染 404建議第一步看 ViewResolver 的 prefix 和 suffix 是否配置正確。InternalResourceViewResolver 的 prefix 填錯(cuò)比如少了開(kāi)頭的斜杠或者目錄和真實(shí)結(jié)構(gòu)不一致就會(huì)轉(zhuǎn)發(fā)到一個(gè)不存在的路徑。第二步看 ViewResolver 的順序如果配置了多個(gè)解析器順序不對(duì)前面的解析器可能把視圖名當(dāng)成不可解析的邏輯名直接拋異常。第三步看模型數(shù)據(jù)是否在渲染時(shí)仍然有效比如用了重定向 redirect: 前綴模型數(shù)據(jù)如果不是用 RedirectAttributes 傳遞到下一次請(qǐng)求自然就丟失了。還有響應(yīng)亂碼這類(lèi)問(wèn)題在純 JSON 項(xiàng)目里不常見(jiàn)但在老 JSP 項(xiàng)目里很常見(jiàn)。亂碼一般源于編碼不一致請(qǐng)求本身是 UTF-8響應(yīng)卻按 ISO-8859-1 輸出。如果項(xiàng)目整體都是 UTF-8又出現(xiàn)部分接口亂碼往往是某個(gè)過(guò)濾器或攔截器在輸出響應(yīng)前改了字符編碼。還有一種情況是 ResponseBody 中文被轉(zhuǎn)碼成了 ? 號(hào)這個(gè)問(wèn)題多半是映射層的編碼配置不對(duì)。建議在配置中統(tǒng)一指定 server.servlet.encoding.forcetrue以及為 HttpMessageConverter 設(shè)置 UTF-8 字符集從根上解決。4.4 面試追問(wèn)備考清單既然題目是面試場(chǎng)景這里我把高頻追問(wèn)整理了一下。面試官不會(huì)只問(wèn)“流程是什么”更可能接著問(wèn)“為什么這里要這么做”“某個(gè)環(huán)節(jié)是否可替換”“出現(xiàn)異常如何流轉(zhuǎn)”。我把自己比較認(rèn)可的答法要點(diǎn)列一下為什么需要 HandlerAdapter直接把 Controller 方法拿來(lái)反射調(diào)用不行嗎 答因?yàn)?Spring MVC 的方法形態(tài)非常豐富RequestBody、PathVariable、Callable、StreamingResponseBody 等都需要不同的處理邏輯Adapter 把這些差異收束到統(tǒng)一的執(zhí)行接口上便于擴(kuò)展和維護(hù)。HandlerMapping 匹配失敗的是怎么處理的 答返回 null繼續(xù)下一個(gè) HandlerMapping。全部沒(méi)有匹配到時(shí)拋出 NoHandlerFoundException這個(gè)異常只有配置了 throwExceptionIfNoHandlerFound 時(shí)才會(huì)明確拋出否則可能直接返回 404 頁(yè)面。攔截器 preHandle 返回 false 之后會(huì)做什么 答不會(huì)繼續(xù)執(zhí)行后續(xù)攔截器和目標(biāo)方法但會(huì)執(zhí)行前面已經(jīng)創(chuàng)建好的攔截器的 afterCompletion 回調(diào)中已完成 preHandle 的部分。注意afterCompletion 里有 try-catch它主要用于清理資源。ControllerAdvice 和 HandlerExceptionResolver 的關(guān)系是什么 答ControllerAdvice 最終會(huì)注冊(cè)為 ExceptionHandlerExceptionResolver 的一個(gè)全局配置通過(guò)它可以把不同異常分發(fā)到對(duì)應(yīng)的方法處理并支持返回視圖或響應(yīng)體。異步請(qǐng)求 DeferredResult 和 Callable 在流程上有什么差別 答Callable 會(huì)讓 Spring MVC 把請(qǐng)求提交到任務(wù)執(zhí)行器異步計(jì)算DeferredResult 則允許業(yè)務(wù)線(xiàn)程自己決定何時(shí)設(shè)置結(jié)果。流程上都會(huì)從 DispatcherServlet 回歸到容器線(xiàn)程做響應(yīng)但中間會(huì)釋放 Tomcat 工作線(xiàn)程。ResponseBody 和 ResponseEntity 有什么區(qū)別 答ResponseBody 表示把返回值寫(xiě)進(jìn)響應(yīng)體ResponseEntity 可以同時(shí)控制 HTTP 狀態(tài)碼、響應(yīng)頭和響應(yīng)體。兩者在返回值處理器上走的是不同的處理器實(shí)現(xiàn)ResponseEntity 還要額外處理 header。這類(lèi)問(wèn)題答順了會(huì)讓面試官覺(jué)得不是死記硬背而是真正寫(xiě)過(guò)多輪請(qǐng)求鏈路代碼、排查過(guò)相關(guān)故障的人。我建議在回答時(shí)搭配一兩個(gè)自己真正調(diào)試過(guò)的小例子比如“我遇到過(guò) preHandle 返回 false 導(dǎo)致接口無(wú)響應(yīng)的問(wèn)題從日志里看到業(yè)務(wù)方法沒(méi)執(zhí)行一路排查才定位到攔截器邏輯”。這種細(xì)節(jié)比任何理論都有說(shuō)服力。最后再分享一個(gè)小技巧讀源碼時(shí)不要只看一個(gè)版本建議拿 Spring Framework 5.3.x 和 Spring Boot 2.7.x 的組合起步這套組合的源碼在本地加斷點(diǎn)非常順。等把 doDispatch 的路徑看熟了再去看 Spring Boot 3 基于 jakarta.servlet 的變化你會(huì)發(fā)現(xiàn)核心設(shè)計(jì)并沒(méi)有變變的只是包名和個(gè)別參數(shù)類(lèi)型。這也是面試時(shí)能自信說(shuō)“我基于源碼驗(yàn)證過(guò)”的基礎(chǔ)。