企业官网建设流程全解析

• 教程
• 知识库

导读

本文以 Spring MVC.md 为核心骨架，系统讲解 Spring MVC 框架的运行时工作原理：客户端通过 URL 发起请求后，DispatcherServlet、Handler Mapping、Controller、Model、View Resolver 与 View 之间如何协作，最终将页面响应回浏览器。同时结合本仓库 Interview List.md 中的面试问答、Spring Boot 启动原理、Spring MVC 测试代码 与 React + Spring Boot 联动示例 等仓库资料，为读者提供可直接用于面试作答与项目理解的完整知识体系。阅读完本文，你将能够：说出 Spring MVC 一次完整请求的 7 步处理链路、解释 DispatcherServlet 为何被称为"前端控制器（Front Controller）"、区分 Handler Mapping 与 View Resolver 的职责，并理解从传统 web.xml 配置到现代注解驱动的演进脉络。

本仓库定位为"신입 개발자 전공 지식 & 기술 면접 백과사전"（新人开发者专业知识与技术面试百科全书），Spring MVC.md 开篇即强调："스프링 MVC 프레임워크가 동작하는 원리를 이해하고 있어야 한다"（必须理解 Spring MVC 框架的运作原理），可见该主题是技术面试的核心考点。

一、什么是 Spring MVC：请求驱动的 MVC 框架

Spring MVC 是 Spring 框架中基于 MVC（Model-View-Controller）模式构建的 Web 框架。它的核心思想是通过"请求驱动"（Request-Driven）的方式，由前端的控制器（DispatcherServlet）统一接收客户端请求，再依次分派给负责业务处理的 Controller、负责数据装载的 Model 以及负责渲染页面的 View，最终把完整页面响应给客户端。

当客户端通过 URL 向服务器发起请求时，Spring 框架内部会执行一整套标准化的处理流程。本仓库 Interview List.md 的"스프링（Spring）"板块将其归纳为如下要点：

DispatcherServlet 是服务器在接收请求之前，先行完成公共处理任务、再把任务委托给合适的细粒度控制器（세부 컨트롤러）的"前端控制器"。

因此，理解 Spring MVC 的关键在于抓住两条主线：

1. 一条请求的完整生命周期：从浏览器发出 URL 到页面渲染完成、响应回客户端；
2. 四大核心组件的分工协作：DispatcherServlet、Handler Mapping、Controller、View Resolver（外加 Model 与 View）。

二、MVC 处理全过程：一次请求的 7 个步骤

Spring MVC 框架的运作可以用"客户端通过 URL 请求服务器时，Spring 框架的完整动作序列"来概括。以下是完整的请求处理链路（对应原文档"### MVC 진행 과정"章节）：

1. 请求进入：客户端向服务器发起 URL 请求，request 从 Web 浏览器发送到 Spring 框架。
2. 处理器映射：DispatcherServlet接收到 request 后，通过Handler Mapping查找负责处理该 URL 的 Controller，并定位到对应处理逻辑。
3. 请求转发与 Model 构建：DispatcherServlet 将 request 转发给找到的Controller，并构建处理请求所需的Model。
4. 数据获取：Model中，页面处理所需的信息通过访问 Database、执行查询语句（쿼리문）来取得。
5. Model 回传与组装：数据库返回的数据作为 Model 信息响应给 Controller，Controller 接收后完成 Model 的组装，再将其交给 DispatcherServlet。
6. 视图解析：DispatcherServlet 通过View Resolver查找 request 对应的 view 文件并取得它。
7. 渲染与响应：将 Model 传给取得的 View 页面文件，完成要发送给客户端的页面，最终把渲染完成的 View 响应给客户端并输出到屏幕。

将上述过程映射到角色上，可以形成下面的责任链：

浏览器/客户端 │ ① 发起 URL 请求 ▼ DispatcherServlet（前端控制器） │ ② 通过 Handler Mapping 定位 Controller ▼ Controller（后端控制器） │ ③④ 构建 Model 并访问 Database 获取数据 ▼ Model（页面处理所需数据） │ ⑤ 数据返回并组装完成，交回 DispatcherServlet ▼ DispatcherServlet │ ⑥ 通过 View Resolver 查找 view 文件 ▼ View（页面模板，注入 Model 完成渲染） │ ⑦ 渲染完成的页面响应给客户端 ▼ 浏览器/客户端 显示页面

这条链路直观地体现了 Spring MVC 的**"中央调度 + 分而治之"**设计：所有请求先汇聚到唯一入口（DispatcherServlet），再由它分派给各司其职的组件，每个组件只负责自己那一环，互不耦合。

三、核心组件逐一拆解

3.1 DispatcherServlet：处理一切请求的中心控制器

DispatcherServlet是整个 Spring MVC 的核心入口。可以把它理解为"处理所有 request 的中心控制器（중심 컨트롤러）"：它在 Servlet 容器中，对通过 HTTP 协议进入的所有 request在最前端进行**集中式（중앙집중식）**处理，扮演着关键角色。

DispatcherServlet的重要性还体现在框架演进的历史脉络上：

• 传统方式（web.xml 时代）：在引入 DispatcherServlet 之前，每一个 Servlet 都必须手工注册到web.xml中，并逐一配置 URL 映射，配置繁琐且难以维护；
• 现代方式：DispatcherServlet 统一接管所有请求，先完成公共处理（如编码、参数解析、异常处理等），再把具体业务委托给合适的细粒度控制器，web.xml的角色被大幅缩减，开发工作因此变得非常便利。

本仓库 Interview List.md 也补充了同样的结论：DispatcherServlet 使得原本承载大量 Servlet 注册职责的web.xml功能被大幅缩减；因为 DispatcherServlet 的存在，MVC 模式得以在 Web 开发中落地，为开发者带来了巨大的便利。

此外，DispatcherServlet 与框架其他部分有着清晰的边界：

• 与安全过滤器的关系：Spring Security 以Filter形式位于 DispatcherServlet 的前端，请求在到达 DispatcherServlet 之前先被 Filter 拦截以校验访问权限（详见 Spring Security 文档）。这解释了 Spring MVC 请求链路的最外层边界：Filter（如 Spring Security）→ DispatcherServlet → Controller。
• 与启动方式的关系：在 Spring Boot 中，@SpringBootApplication与SpringApplication.run()负责启动内嵌 WAS 并自动装配包含 DispatcherServlet 在内的整个 MVC 基础设施，开发者无需再手工配置web.xml中的 Servlet 映射，这正是"web.xml 职责收缩"在 Spring Boot 时代的最终形态。

3.2 Handler Mapping：URL 与控制器的"寻址器"

Handler Mapping的职责是：根据客户端的请求 URL，找出应当由哪个 Controller 来处理该请求，并把这个信息传递给 DispatcherServlet。

在原文档基础上，结合本仓库的实践代码可以看得更具体。在 React + Spring Boot 联动示例 的MyController.java中，控制器通过@GetMapping("/{name}.html")声明了对带路径变量的 URL 的处理，而 Handler Mapping 正是负责解析这类映射关系并"找到它"的组件：

@Controller public class MyController { @GetMapping("/{name}.html") public String page(@PathVariable String name, Model model) { model.addAttribute("pageName", name); return "page"; } }

这里可以看到几个与 Handler Mapping 直接相关的知识点：

• 在控制器中，URL 与处理方法之间通过@RequestMapping（或其便捷变体@GetMapping、@PostMapping等）进行映射，Handler Mapping 的任务就是发现并解析这些注解；
• @PathVariable String name让 URL 中的动态路径片段（如/home.html中的home）被绑定到方法参数上，这是 Handler Mapping 在"URL → 控制器方法"匹配过程中完成的参数解析工作的一部分；
• 方法返回值"page"是一个逻辑视图名，它并不直接是页面文件路径，而是交由后面的 View Resolver 去解析，这正体现了 Handler Mapping 与 View Resolver 的分工差异。

面试要点：Handler Mapping 只负责"找到该由谁处理"，它本身不执行业务逻辑；DispatcherServlet 根据 Handler Mapping 的结果将请求转发给对应的 Controller 方法。

3.3 Controller：处理实际请求的后端控制器

Controller是真正处理请求的地方。如果说 DispatcherServlet 是"前端控制器（Front Controller）"，那么 Controller 就是"后端控制器（Backend Controller）"。

Controller 的职责可概括为两点：

1. 执行业务请求的处理逻辑（可进一步委托给 Service 层）；
2. 把 Model 的处理结果组装好，返回给 DispatcherServlet。

从 Interview List.md 的注解速查表来看，Controller 在现代 Spring 中通常通过以下注解完成注册与依赖组织：

• @Controller：将类注册为 Spring MVC 控制器，其效果等同于传统dispatcher-servlet.xml中通过<bean>标签定义控制器；
• @RequestMapping：将特定方法与请求的 URL 匹配起来；
• @Autowired：自动完成依赖注入；
• @Service：注册处理业务逻辑的服务类；
• @Repository：注册 DAO（数据访问层）类。

由此可以看到，Controller 并不是孤立工作的：它依赖@Service层的业务逻辑与@Repository/DAO 层的数据访问，再把结果填充进 Model。仓库中的 JPA 文档 展示了这一分层中数据层的一种现代实现：通过 JPA（Java 提供的 ORM 标准 API）代替手写 SQL 完成数据库的存取。

3.4 View Resolver：决定最终视图的解析器

View Resolver的职责是：根据 Controller 的处理结果，决定要创建（渲染）哪个 view。

它有以下特征：

• Controller 返回的通常是逻辑视图名（如前面示例中的"page"），而不是物理文件路径；
• View Resolver 负责把逻辑视图名解析为真正的视图对象或模板文件（如 JSP、Thymeleaf 等）；
• View Resolver 有多种实现类型，应当根据场景灵活选用，例如：
  • 基于 JSP 的InternalResourceViewResolver（适用于传统 JSP 页面）；
  • 基于模板引擎的ThymeleafViewResolver、FreeMarkerViewResolver等；
  • 对于返回 JSON 的 REST API 场景，则由消息转换器（MessageConverter）直接输出数据，无需页面视图。

在原文档 React + Spring Boot 联动示例 中可以看到 View Resolver 的实际落点：Controller 返回逻辑视图名"page"，项目在src/main/webapp/jsp/目录下提供page.jsp作为物理视图文件，由 View Resolver 完成两者之间的桥接，并把 Model 中的pageName注入到页面模板（${pageName}）中完成渲染。

3.5 Model 与 View：数据的容器与页面的载体

• Model：承载"页面处理所需的信息"。原文档强调，Model 中的数据通过访问 Database、执行查询语句取得——在现代分层架构中，这一步通常由 Controller → Service → Repository（DAO）逐层协作完成，而非 Controller 直接写 SQL（见 JPA.md 中"JPA 帮助开发者摆脱手写 SQL"的论述）。
• View：负责把 Model 中的数据与页面模板结合，渲染出最终发送给客户端的完整 HTML 页面。

DispatcherServlet 将 Model 数据交给 View 后，View 完成"数据 + 模板 = 页面"的组装，最终响应给客户端。

四、与请求处理相关的扩展知识

4.1 Spring Security：DispatcherServlet 前的第一道 Filter

在 Spring MVC 的完整请求链路中，DispatcherServlet 并不是请求到达的第一个处理者。根据仓库 Spring Security 文档 的说明：

Spring Security 以 Filter 形态位于 DispatcherServlet 的前端。在请求进入 Dispatcher 之前，该 Filter 会拦截请求、确认客户端对资源的访问权限；若权限不足，则自动重定向到认证请求页面。

因此一条完整的带安全校验的请求链路是：

客户端请求 → Spring Security Filter 链（如 UsernamePasswordAuthenticationFilter、JWT 认证 Filter 等） → DispatcherServlet → Handler Mapping → Controller → Model → View Resolver → View → 响应客户端

理解这一层级关系，有助于在面试中把"Spring MVC 请求处理原理"与"认证授权机制"串成一条完整的知识链。

4.2 Bean Scope：MVC 环境下的对象生命周期

请求链路中的每个组件都是 Spring 管理的 Bean，而 Bean 的存活范围（Scope）会直接影响多请求并发场景下的行为。仓库 Bean Scope 文档 指出：

• Spring 中 Bean 默认以singleton方式创建（整个 IoC 容器内仅一个实例，供所有请求共享）；
• 除singleton外还有prototype、request、session、global session等 Scope；
• 其中request、session、global session仅在 MVC Web 应用中可用——request表示 Bean 的生命周期与单个 HTTP Request 一致，session表示与单个 HTTP Session 一致。

这与本文主题直接相关：DispatcherServlet 每收到一次 HTTP 请求，就会走一遍完整的 MVC 流程，而request/sessionScope 的 Bean 正是围绕"每个请求/每个会话"这一生命周期被创建和销毁的。

4.3 Spring MVC 的自动化测试

Spring MVC 框架还提供了强大的测试支撑，仓库 Test Code 文档 展示了针对 Controller 的典型测试写法：

@RunWith(SpringRunner.class) @WebMvcTest(controllers = HomeController.class) public class HomeControllerTest { @Autowired private MockMvc mvc; @Test public void home_return() throws Exception { String home = "home"; mvc.perform(get("/home")) .andExpect(status().isOk()) .andExpect(content().string(home)); } }

其中与 Spring MVC 直接相关的两个要点：

• @WebMvcTest：仅聚焦于 Spring MVC 层的切片测试注解，只装配 Controller 及相关 MVC 组件（可以理解为只拉起 DispatcherServlet 一层的测试环境）；
• MockMvc：模拟向 Spring MVC 发起 HTTP GET/POST/DELETE 请求，并通过perform(...).andExpect(...)验证状态码与响应内容，是验证"DispatcherServlet → Handler Mapping → Controller → 响应"这条链路正确性的标准手段。

五、面试速记清单

综合原文档与仓库资料，将本节知识浓缩为面试高频问答要点：

六、总结

Spring MVC 框架的运作原理可以浓缩为一句话：所有请求先汇聚到 DispatcherServlet 这一唯一入口，由它借助 Handler Mapping 定位 Controller、借助 View Resolver 定位 View，Controller 负责执行业务并组装 Model，View 负责将 Model 渲染成页面，最终响应给客户端。

这条"请求驱动"的处理链路上，每个组件都职责单一、边界清晰，这正是 Spring MVC 易于理解、易于扩展、也易于测试的根本原因。对于准备技术面试的开发者而言，能完整复述上述 7 步处理流程、能说清四个核心组件的分工、能解释 web.xml 到注解驱动的演进逻辑，就已牢牢掌握了这道高频考点。可进一步结合本仓库的 Spring MVC.md 原文、Interview List.md 中的 DispatcherServlet 问答以及 Spring Boot 测试示例 反复巩固。

• 教程
• 知识库