DispatcherServlet是Spring MVC核心，作为前端控制器统一接收请求，通过HandlerMapping查找映射、HandlerAdapter执行处理器、ViewResolver解析视图，完成请求处理全流程。
Spring MVC处理请求的核心，在于DispatcherServlet这个中枢神经，它协调着一系列组件来完成从接收请求到返回响应的整个过程，本质上，这是一个高度解耦、职责分明的管道式操作，确保了应用的灵活性和可维护性。
Spring MVC处理请求的流程，从一个用户在浏览器中敲下URL并回车那一刻就开始了。整个过程可以看作是一场精心编排的接力赛。当HTTP请求抵达Web服务器（如Tomcat），并被配置好的DispatcherServlet拦截时，它便成为了这场比赛的“发令员”。
首先，DispatcherServlet会根据请求的URL，向一系列注册好的HandlerMapping询问：“这个请求应该由哪个Controller方法来处理？” HandlerMapping会返回一个HandlerExecutionChain，这不仅仅是Controller方法本身，还可能包含一系列预处理和后处理的拦截器（Interceptor）。
拿到HandlerExecutionChain后，DispatcherServlet并不会直接调用Controller方法，而是将这个任务交给HandlerAdapter。为什么需要HandlerAdapter呢？因为Controller方法的签名可能千变万化，有的接受HttpServletRequest和HttpServletResponse，有的直接绑定Model对象，有的返回String，有的返回ModelAndView。HandlerAdapter的存在，就是为了适配这些不同类型的Controller，以统一的方式调用它们，并处理方法的返回值。
Controller方法执行完毕后，通常会返回一个ModelAndView对象（或者一个String，一个Map，一个POJO，等等，Spring会将其包装成ModelAndView）。这个ModelAndView包含了两个关键信息：逻辑视图名和模型数据。
接下来，DispatcherServlet会找到合适的ViewResolver。ViewResolver的作用，顾名思义，就是将逻辑视图名解析成真正的视图对象（如JSP文件、Thymeleaf模板、Freemarker模板等）。
最后，View对象会利用模型数据进行渲染，生成最终的HTML、JSON或其他格式的响应内容，并将其写回到HttpServletResponse中。至此，一个完整的请求处理周期才算画上句号，浏览器也终于能看到它想要的内容了。
为什么说DispatcherServlet是Spring MVC请求处理的核心？
在我看来，DispatcherServlet之于Spring MVC，就像一个乐队的指挥。它本身不演奏任何乐器，但它协调着整个乐团的运作，确保每个乐手（组件）在正确的时间点，以正确的方式发出声音。如果没有DispatcherServlet，整个Spring MVC框架的解耦和灵活性就无从谈起。
它的核心地位体现在几个方面：它是前端控制器（Front Controller），所有请求的入口点都统一到它这里，避免了为每个请求编写一个Servlet的繁琐。这种模式极大地简化了开发，也使得全局性的操作（如安全检查、日志记录、国际化）能够集中处理。DispatcherServlet通过委派机制，将具体的任务分发给不同的组件，例如HandlerMapping负责查找处理器，HandlerAdapter负责执行处理器，ViewResolver负责解析视图。这种职责分离的设计，不仅让各个组件可以独立演进，也让开发者可以根据需求替换或定制这些组件，而无需修改DispatcherServlet本身的代码。比如，你想用Thymeleaf替换JSP，只需更换ViewResolver即可，DispatcherServlet依然稳如泰山。它就像一个高度智能的交通枢纽，将各种车辆（请求）导向正确的目的地，同时还能根据路况（配置）灵活调整路线。
Controller方法是如何被Spring MVC找到并执行的？
初次接触Spring MVC时，我曾好奇，框架是怎么知道哪个URL对应哪个Java方法的。这背后，是HandlerMapping和HandlerAdapter的默契配合。
当DispatcherServlet收到请求后，它会遍历所有注册的HandlerMapping实例。最常见的是
RequestMappingHandlerMapping，它会扫描所有
@Controller注解的类和
@RequestMapping注解的方法，构建一个URL到具体处理方法的映射表。当请求进来时，它会根据请求的URL、HTTP方法（GET、POST等）、参数类型等信息，从这个映射表中找到最匹配的处理方法，并将其连同可能需要的拦截器一起封装成一个
HandlerExecutionChain返回。这个过程，有点像在图书馆根据书名（URL）找到具体的书（Controller方法）。
拿到
HandlerExecutionChain后，DispatcherServlet会将它交给
HandlerAdapter。同样，最常见的是
RequestMappingHandlerAdapter。它的职责是真正地“调用”Controller方法。但这里的“调用”并非简单地反射执行。它需要处理方法参数的绑定，比如将URL路径变量、请求参数、请求体中的JSON/XML数据等，正确地映射到Controller方法的参数上。它还会处理方法返回值，例如将方法返回的String解析为逻辑视图名，将POJO转换为JSON响应等。
HandlerAdapter的存在，使得Controller方法可以拥有各种各样的签名，而无需关心底层的Servlet API细节，这极大地提高了开发效率和代码的整洁性。这种设计，在我看来，是Spring MVC在抽象层面上做得非常漂亮的地方，它屏蔽了底层细节，让开发者能更专注于业务逻辑。
从Controller返回的数据，Spring MVC是如何渲染成最终页面的？
Controller方法执行完毕后，通常会返回一些数据，可能是
String（表示一个视图名）、
ModelAndView对象、或者直接是需要转换为JSON/XML的POJO。Spring MVC需要将这些“逻辑”转化为用户可见的“物理”页面。
如果Controller返回的是一个逻辑视图名（比如
"userList"），DispatcherServlet就会启动视图解析流程。它会遍历配置的
ViewResolver。常见的有
InternalResourceViewResolver（用于JSP）、
ThymeleafViewResolver、
FreeMarkerViewResolver等。每个
ViewResolver都有自己的职责，它会根据逻辑视图名，结合自身配置的前缀和后缀，尝试解析出一个具体的
View对象。例如，
InternalResourceViewResolver可能会将
"userList"解析为
/WEB-INF/views/userList.jsp。如果找到匹配的
ViewResolver，它就会返回一个
View实例。
一旦获得了
View实例，DispatcherServlet就会调用
View的
render()方法，并将Controller方法返回的模型数据（如果有的话）传递给它。
View对象（比如一个JSP页面）会利用这些模型数据，结合自身的模板逻辑，最终生成HTML内容。这个HTML内容随后被写入到HTTP响应中，发送回客户端浏览器。
如果Controller方法直接返回一个POJO对象，并且方法上标注了
@ResponseBody注解，那么Spring MVC会启用
HttpMessageConverter机制。
HttpMessageConverter会将POJO对象序列化成JSON或XML格式，然后直接写入HTTP响应体中，而不会经过视图解析流程。这种方式在构建RESTful API时非常常见和高效。这整个过程，就像一个专业的出版社，根据作者（Controller）提供的原稿（数据和逻辑视图名），选择合适的排版工具（ViewResolver），最终印刷出精美的书籍（渲染后的页面）。
