Spring MVC 架构与请求处理全链路解析:从 DispatcherServlet 到响应返回
作者：萧瑟余晖
定位：第 01 篇，讲透 MVC 设计模式、各核心组件职责、一次请求的完整处理链路与 DispatcherServlet 装配
适用版本：Spring Framework 6.x（JDK 17+）
一、MVC 模式
1.1 三角色
| 角色 | 职责 | 在 Spring MVC 中 |
|---|---|---|
| Model | 数据与业务状态 | 方法返回的数据/Model 对象 |
| View | 呈现 | 模板（Thymeleaf）或 JSON（REST） |
| Controller | 接收请求、编排、返回 | @Controller/@RestController 方法 |
1.2 价值
职责分离：请求入口（Controller）与业务、呈现解耦；视图可替换（同一数据渲染 HTML 或 JSON）；Controller 薄、逻辑下沉到 Service，便于测试。
浏览器/客户端 → Controller（编排） → Service（业务） → Model
↓
View/JSON 呈现二、核心组件
理解这六个组件就理解了 Spring MVC：
| 组件 | 职责 | 可定制 |
|---|---|---|
| DispatcherServlet | 前端控制器，所有请求统一入口 | 可多个、可换映射 |
| HandlerMapping | URL → Handler（找到处理方法） | 可加自定义 |
| HandlerAdapter | 适配并调用 Handler（解析注解、参数） | 主要用 RequestMappingHandlerAdapter |
| Handler | 你的 @RequestMapping 方法 | 业务代码 |
| ViewResolver | 视图名 → View（传统 MVC） | REST 场景不用 |
| HttpMessageConverter | 对象 ↔ 请求/响应报文 | JSON/XML 转换器 |
前端控制器模式：所有请求经 DispatcherServlet 统一分发，避免每个资源各自处理入口逻辑——这是 MVC 框架的通用骨架。
三、请求处理链路
一次请求的完整流程（面试必背）：
① 请求到达 DispatcherServlet
│
② HandlerMapping 匹配：根据 URL 找到 Handler（处理方法）+ 拦截器链
│
③ HandlerAdapter 准备调用：解析方法参数（@RequestParam/@RequestBody 等，见 02 篇）
│
④ 执行 Handler（你的业务方法）
│
⑤ 处理返回值：
├── 传统：返回视图名 → ViewResolver 解析 → View 渲染
└── REST：@ResponseBody → HttpMessageConverter 序列化为 JSON
│
⑥ 响应写回客户端
│
异常：任意环节抛异常 → HandlerExceptionResolver 处理（见 04 篇）关键认知：
- Handler 是方法不是类：HandlerMapping 定位到具体的 @RequestMapping 方法；
- REST 与传统共用同一链路，差异只在第⑤步（消息转换 vs 视图渲染）；
- 拦截器在②③之间执行（04 篇展开）。
四、DispatcherServlet 装配
4.1 Boot 下的自动装配
WebMvcAutoConfiguration 自动注册 DispatcherServlet，映射到 /，并装配默认的 HandlerMapping、HandlerAdapter、消息转换器。
4.2 上下文结构
DispatcherServlet 持有一个 WebApplicationContext（Servlet 级），通常以根容器（Root Context，业务 Bean）为父——子容器可见父容器 Bean，反之不行。Boot 中两者合一，这个分层在理解 XML 时代遗留项目时仍重要。
4.3 多 Servlet 场景
默认一个 DispatcherServlet（/） 可注册多个，各自不同 url-pattern（如 /app/*、/admin/*） 每个有独立的 WebApplicationContext
五、总结
- MVC：Model/View/Controller 职责分离，Controller 薄、逻辑下沉。
- 六大组件：DispatcherServlet 统一入口、HandlerMapping 找方法、HandlerAdapter 解析调用、Handler 业务方法、ViewResolver/HttpMessageConverter 处理输出。
- 请求链路：到达 → 映射 → 参数解析 → 执行 → 结果处理（视图或 JSON）→ 写回；异常交异常解析器。
- 装配：Boot 自动注册映射 /；理解 Web 上下文父子结构；多 Servlet 各自独立上下文。
六、常见高频面试题
1. 描述一次请求在 Spring MVC 中的完整处理流程。
要点：请求到达 DispatcherServlet → HandlerMapping 按 URL 匹配到 Handler（@RequestMapping 方法）与拦截器链 → HandlerAdapter 解析方法参数并调用 → Handler 执行业务返回 → 处理返回值：传统走 ViewResolver 渲染视图，REST（@ResponseBody）走 HttpMessageConverter 序列化为 JSON → 写回响应。任意环节异常交 HandlerExceptionResolver 处理。
2. DispatcherServlet 是什么？为什么叫前端控制器？
要点：它是 Spring MVC 的统一请求入口，所有请求先到它，再由它分发给具体 Handler——这是前端控制器（Front Controller）模式：集中处理入口逻辑（映射、参数解析、异常、视图），避免每个资源各自实现。好处是流程统一、横切能力（拦截、安全、日志）有统一挂载点。Boot 自动装配它映射到 /。
3. HandlerMapping 和 HandlerAdapter 的区别？
要点：HandlerMapping 负责"找"——根据请求（URL/注解）定位到具体的 Handler 及其拦截器链；HandlerAdapter 负责"调"——适配并调用 Handler，解析方法参数、处理返回值（@RequestParam/@RequestBody 等由它驱动）。常用实现：RequestMappingHandlerMapping（处理 @RequestMapping）与 RequestMappingHandlerAdapter。分离二者使框架可扩展不同的处理器风格。
4. @Controller 和 @RestController 的区别？
要点：@RestController = @Controller + @ResponseBody。@Controller 的方法默认返回视图名（交给 ViewResolver 渲染）；@RestController 的方法返回值直接经 HttpMessageConverter 序列化为响应体（通常 JSON），用于 REST API。需要"部分方法返回视图、部分返回 JSON"时用 @Controller + 局部 @ResponseBody。
5. HttpMessageConverter 的作用？常见有哪些？
要点：负责对象与 HTTP 报文之间的双向转换——把请求体反序列化为方法参数（@RequestBody），把返回值序列化为响应体（@ResponseBody）。常见：MappingJackson2HttpMessageConverter（JSON）、StringHttpMessageConverter（字符串）、FormHttpMessageConverter（表单）、XML 转换器等。内容协商（Accept/Content-Type）决定选哪个转换器。
6. 什么是内容协商？
要点：根据请求与响应头协商数据格式。请求侧：Content-Type 声明请求体格式（决定反序列化用哪个转换器）；响应侧：Accept 声明客户端期望格式，服务端结合可用的 HttpMessageConverter 与扩展名/参数决定返回 JSON 还是 XML 等。Boot 默认以 JSON 为主。这让同一接口可服务不同格式的客户端。
7. REST 风格和传统 MVC 在链路上的差异在哪？
要点：前四步完全一致（映射、参数解析、执行）。差异在返回值处理：传统返回视图名，经 ViewResolver 解析成 View 再渲染模型数据；REST 用 @ResponseBody（或 @RestController），返回值直接经 HttpMessageConverter 序列化为报文写回。所以 REST 是 MVC 链路的一种输出形态，不是另一套框架。
8. Spring MVC 的父子容器是怎么回事？
要点：传统结构有根容器（Root，Service/DAO 等业务 Bean）与 DispatcherServlet 的 Web 子容器（Controller 等 Web Bean）；子可见父、父不可见子，避免 Web 层污染业务层。Boot 中合并为单一容器，不再区分。理解它有助于维护老的 XML 项目和解释某些 Bean 可见性问题。
9. 如何自定义 HandlerMapping 或加多个？
要点：实现 HandlerMapping 接口并注册为 Bean，DispatcherServlet 启动时收集所有 HandlerMapping 按 order 排序，请求到来时依次尝试直到匹配。可用于自定义路由规则（如基于版本头的路由）。常见扩展点还包括自定义 HandlerAdapter、HandlerInterceptor。不过多数场景用 @RequestMapping 注解驱动即可，无需自定义。
10. 为什么 Spring MVC 是同步阻塞模型？有什么影响？
要点：基于 Servlet 规范，默认每个请求占用一个线程从入口到响应结束（阻塞式处理，含等待下游/DB 的时间）。影响：高并发下线程数成为吞吐瓶颈，线程被 IO 等待占用而非干活。对策：扩大线程池（治标）、异步方法释放线程（部分缓解）、或换响应式栈（WebFlux，06 篇）与异步 Servlet。虚拟线程（JDK 21）也在改变这一模型的代价。
到此这篇关于Spring MVC 架构与请求处理全链路解析:从 DispatcherServlet 到响应返回的文章就介绍到这了,更多相关Spring MVC架构与请求内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！