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