ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

一、SpringMVC核心执行组件（前置铺垫）

请求流程的本质是核心组件协同配合完成请求分发、业务处理、结果响应，先明确各组件职责是理解流程的关键：

• DispatcherServlet（前端控制器）：整个流程的核心调度中心，接收所有客户端请求，统一分发任务，协调其他组件执行，是SpringMVC的入口和出口。
• HandlerMapping（处理器映射器）：根据请求URL、请求方法等信息，查找匹配的Handler（处理器/Controller）和对应的拦截器，返回处理器执行链。
• HandlerAdapter（处理器适配器）：适配不同类型的Handler，统一调用规则，执行具体的Controller业务方法，屏蔽底层Handler实现差异。
• Handler（处理器/Controller）：开发人员编写的业务控制器，承载核心业务逻辑，处理请求参数、调用Service层、返回数据/视图。
• ViewResolver（视图解析器）：将Controller返回的逻辑视图名，解析为具体的物理视图对象（如JSP、Thymeleaf页面）。
• View（视图）：负责渲染数据，将模型数据填充到视图中，生成最终响应内容返回给客户端。
• HandlerInterceptor（拦截器）：流程中的增强组件，可在请求执行前、后、视图渲染前做权限校验、日志打印等通用操作。

二、SpringMVC完整请求执行流程（分步详解）

整个流程遵循“统一入口、分层处理、闭环响应”的原则，从客户端发起请求到最终页面展示，共分为9个核心步骤，每一步环环相扣：

步骤1：客户端发起HTTP请求

用户通过浏览器、接口工具等发起HTTP请求（如GET/POST请求），请求携带URL、请求参数、请求头信息，目标指向部署SpringMVC项目的Web服务器（如Tomcat）。

步骤2：Web服务器转发请求至DispatcherServlet

Web服务器接收请求后，根据web.xml或SpringBoot自动配置的映射规则，将所有请求统一转发给DispatcherServlet（前端控制器），DispatcherServlet是SpringMVC的唯一入口，接管后续所有处理逻辑。

步骤3：DispatcherServlet调用HandlerMapping查找处理器

前端控制器不直接处理业务，而是委托HandlerMapping解析请求：根据请求URL、请求方法、请求参数等匹配条件，扫描容器中所有标注@Controller/@RequestMapping的组件，找到对应的Handler（Controller方法），并封装为HandlerExecutionChain（处理器执行链）（包含Handler+对应拦截器）返回给DispatcherServlet。这里的拦截器并非框架内置固定组件，而是由开发人员根据业务需求自定义实现的增强组件，开发者通常通过实现HandlerInterceptor接口、重写核心方法来定义拦截逻辑，再通过配置文件或注解注册到Spring容器中，由框架统一管理并纳入执行链调用。

若未找到匹配的Handler，直接返回404错误响应；若找到则进入下一步。

步骤4：DispatcherServlet调用HandlerAdapter适配处理器

由于Handler的实现形式多样，这是SpringMVC兼容历史版本、适配不同开发场景的设计结果：早期SpringMVC并非只有注解式Controller一种处理器形式，还支持实现Controller接口、HttpRequestHandler接口等传统写法，甚至可配置普通Bean作为处理器，框架需要兼容这类历史实现；同时多样化的Handler也能满足不同业务的定制化需求。针对注解式Controller、普通Bean处理器、传统接口实现类等不同形态的Handler，DispatcherServlet会根据Handler类型，找到对应的HandlerAdapter，通过适配器统一调用Handler，屏蔽不同Handler的调用差异，保证执行规范。

步骤5：执行拦截器preHandle方法（前置增强）

在执行Handler业务方法前，DispatcherServlet会遍历处理器执行链中的拦截器，依次调用每个拦截器的preHandle()方法。

若某一拦截器返回false，流程直接中断，不再执行后续业务逻辑，直接返回响应；若全部返回true，则进入业务方法执行阶段。

步骤6：HandlerAdapter执行Controller业务方法

HandlerAdapter调用匹配的Controller业务方法，完成核心操作：接收请求参数、参数绑定与类型转换、调用Service层业务逻辑、处理数据、返回ModelAndView（模型数据+逻辑视图名）或直接返回JSON数据（Restful接口）。

步骤7：执行拦截器postHandle方法（后置增强）

Controller业务方法执行完毕、返回ModelAndView之后，DispatcherServlet会倒序遍历处理器执行链中的自定义拦截器，调用每个拦截器的postHandle()方法。这一步是视图渲染前的最后时机，专门用于对ModelAndView里的模型数据、逻辑视图名做二次修改、参数补充等后置增强操作，这也是该步骤必须放在视图解析前的核心原因。

Controller方法执行完毕后，DispatcherServlet再次遍历拦截器，倒序调用每个拦截器的postHandle()方法，可对ModelAndView中的数据或视图名做二次修改。

步骤8：视图解析与渲染（非Restful接口）

1. 视图解析：若Controller返回逻辑视图名，DispatcherServlet将视图名交给ViewResolver，解析为具体的物理View对象（如/WEB-INF/views/index.jsp）；2. 视图渲染：View对象接收Model数据，将数据填充到视图模板中，生成HTML等响应内容；3. Restful接口特殊处理：若Controller标注@ResponseBody，直接通过消息转换器将返回对象序列化为JSON，全程跳过视图解析、视图渲染环节。

步骤9：执行拦截器afterCompletion方法并返回响应

视图渲染完成（或接口数据响应完毕）后，DispatcherServlet依旧倒序调用所有拦截器的afterCompletion()方法。该方法属于流程收尾方法，无论请求是否异常、是否中断都会执行，主要用于释放资源、打印收尾日志、清理线程变量等操作，最终DispatcherServlet把完整响应结果返回给Web服务器，再转发给客户端，整个请求流程闭环结束。

视图渲染完成后，DispatcherServlet倒序调用拦截器的afterCompletion()方法（无论流程是否异常都会执行，用于资源释放），最终将渲染后的响应内容返回给Web服务器，再由服务器转发给客户端，完成整个请求闭环。

三、流程核心总结

一句话概括SpringMVC请求流程：客户端请求→DispatcherServlet统一接收→HandlerMapping找Controller→HandlerAdapter执行业务→视图解析渲染→返回响应，拦截器贯穿全流程做增强处理。

整个流程实现了请求分发与业务逻辑解耦，开发者只需关注Controller层的业务编写，无需关心底层请求转发、适配、渲染细节，大幅提升开发效率。

四、关键细节补充

• SpringBoot中无需手动配置DispatcherServlet，自动装配完成初始化；
• Restful接口（@ResponseBody）会跳过视图解析器，直接通过消息转换器输出数据；
• 异常处理：流程中出现异常会被DispatcherServlet捕获，交给HandlerExceptionResolver处理。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花