一、先别被名字唬住

三个字母拆开，其实没什么玄的。Model 是模型，就是”要显示的数据”；View 是视图，就是”长什么样”；Controller 是控制器，就是”这一下该谁处理”。 MVC 本身是一种”分家”的思想：管数据的别管长相，管长相的别管业务，管业务的别管怎么画。而 Spring MVC，就是这套思想在 Java 里的实现，外加一个总调度台。

二、最好的类比：去医院看病

想明白它，你就想想自己去医院看病的全过程。你进门只需要认识导诊台，不需要知道后面有科室索引表、有分诊护士、有药房——Spring MVC 就是照这个思路设计的。

关键点在这里：病人全程只跟导诊台打交道。这就是“前端控制器“模式最大的好处——入口唯一，内部怎么改都行。加一道安检、换一个药房，病人不用重新学一遍怎么看病。
写代码的时候也是一样。你只需要改中间那个“诊室”，不用去动导诊台的逻辑，更不用告诉浏览器”我们医院装修了”。

三、一次请求，九步走完

不管你的网站多复杂，一次网页请求都是”从 DispatcherServlet 进、从 DispatcherServlet 出”，中间九个角色排班干活。可以把它分成三个阶段来看。

（一）第一阶段：先找到人

1.请求到达。所有请求先交给 DispatcherServlet，它是唯一入口。
2.查映射表。HandlerMapping 拿着网址去找，该由哪个方法处理。3.组装执行链。把处理者和拦截器打包，一起交回给 DispatcherServlet。

（二）第二阶段：真干活

1.适配调用。HandlerAdapter 用一种统一的方式把处理者调起来，不管处理者是什么类型。
2.执行逻辑。轮到 Controller 了——业务判断写在这里，需要数据就去调服务层、查数据库。 3.拿到结果。返回一个 ModelAndView（数据加视图名），或者干脆直接返回一个对象。

（三）第三阶段：出结果

1.解析视图。如果返回的是”success”这种逻辑名，ViewResolver 负责把它变成真实的页面文件。
2.渲染页面。View 把 Model 里的数据填进模板，生成最终的 HTML。
3.写回响应。DispatcherServlet 把结果交给浏览器，一次请求结束。这里有个细节值得记住：第 6 步返回什么，决定了第 7、8 步走不走。返回页面名就去找 View，返回对象就直接变 JSON——今天大量的后端接口，其实只有前六步，压根没有视图什么事。

四、你真正要写的那部分：注解

上面那些组件名（HandlerMapping、ViewResolver 之类），你几乎永远不用自己写，Spring MVC 早就默认配好了。你真正会碰到的，是下面这些注解。

如果只记一条，就记这条：返回”页面名”就去找 View，返回”对象”就变 JSON。

五、四组最容易搞混的概念

下面这四组，是初学阶段最容易绕晕的地方，我们把它们一次摆平

六、它现在长什么样

如果你在准备面试或者做技术选型，下面这几个版本事实用得上。

·当前主线是Spring Framework 7.0（2025 年 11 月发布，最新 7.0.8 / 7.0.9），最低要求 Java 17，基线换到了 Jakarta EE 11。这就是为什么老项目升级时，满屏的 javax. 要全改成jakarta.。7.1 预计 2026 年 11 月。

·6.2 版本的免费支持 2026 年 6 月已经结束；5.3 更早，2024 年 8 月就停了——但很多公司还钉在上面，因为它兼容 Java 8。

顺便说一句：你几乎不会单独”使用 Spring MVC”。实际项目里都是在 Spring Boot 里加一个 web 起步依赖，MVC 自动就位了。

七、和WebX是什么关系

上一篇讲 WebX 的时候，很多人问我它和 Spring MVC 到底什么关系。答案是：它们俩是同一个物种。

WebX 的管道与阀门，就是它自己的拦截器链；那个”总入口”，扮演的就是 DispatcherServlet 的角色。思路完全一样，WebX 只是早生了几年的国产实现。所以你把两份资料放一起看，会发现它们讲的是同一件事的两种叫法。

八、最后一句

Spring MVC 说到底，就是给网站配了一个总调度台。所有请求都从它过一遍，它负责查表找人、催人干活、把结果包装好送回去。

它自己不做业务，只负责调度。你要写的永远只有中间那一环：Controller。