面经策

说下对 Spring MVC 的理解？ ​

  • 标签：后端、Spring

🏛 业务架构师 ​

我对 Spring MVC 的理解分三层：

定位层：它是 Spring 生态的 Web 接入框架，基于 Servlet（现 Jakarta Servlet）体系，把"HTTP 请求 → 业务处理 → 响应"这条链路标准化。核心是 DispatcherServlet 统一接收所有请求，按注册的路由分发给对应 Controller。

业务价值层：

  1. API 契约标准化：注解驱动（@GetMapping、@RequestBody）让接口定义和代码合一，配合 OpenAPI（Swagger）自动生成文档，前后端/跨团队协作成本大幅下降；
  2. 横切能力挂载点：参数校验、异常统一处理、拦截器鉴权都有标准位置，团队规范容易统一执行；
  3. 与生态无缝：依赖注入让 Controller 天然薄（参数校验 + 调 Service + 组装响应），业务逻辑沉淀在 Service 层，利于复用和测试。

架构演进层（2026 视角）：前后端分离成为绝对主流后，MVC 里 ViewResolver 渲染页面职责已边缘化，它实际是"RESTful 服务框架"；同步阻塞模型在常规业务系统（CRUD + 中间件调用）中开发效率和可观测性仍然最优。真正的 I/O 密集高并发场景才考虑 WebFlux，而且如今更多被虚拟线程（JDK 21+，Spring Boot 3.2+ 已良好支持）以更低的心智成本替代。我的选型默认 Spring MVC + 虚拟线程，简单直接，符合业务团队的维护能力。

🏗 系统架构师 ​

Spring MVC 是 Servlet 栈上的 Web 框架，核心是「前端控制器」模式：所有请求汇入 DispatcherServlet，由它统一调度路由、适配、执行与渲染。

  • 主干：请求 → Filter 链 → DispatcherServlet → HandlerMapping 找处理器 → HandlerAdapter 适配执行 → Controller → 返回 ModelAndView 或走 @ResponseBody 由 HttpMessageConverter 序列化；
  • 架构价值：前端控制器是横切能力的收口点——统一鉴权、追踪、异常、内容协商都挂在这条主干上，几百个 Controller 无需各自处理；
  • 无状态 HTTP 是水平扩展的根基：请求-响应模型天然无会话依赖，实例无差别，扩容即加副本，这奠定了它作为分布式服务主力交互形态的地位。

2026 年的选型语境：Spring MVC 仍是默认答案，但要能讲两条演进线：JDK 21 虚拟线程让「每请求一线程」的阻塞模型重新高效，MVC 生态成本最低；IO 密集的网关与聚合层用 WebFlux/Netty 事件循环换更高连接密度。默认 MVC、边缘场景 Reactive，是我的常态决策。

💻 全栈开发专家 ​

Spring MVC 是 Spring 体系里基于 Servlet 规范的 Web 层框架，核心是前端控制器模式：所有请求进入唯一的 DispatcherServlet，由它统一调度"找谁处理（HandlerMapping）→ 怎么调（HandlerAdapter）→ 结果怎么渲染（ViewResolver/HttpMessageConverter）"。

我认为设计最妙的三点：

  1. 注解驱动：@RestController + @GetMapping 一个方法就是一个接口，参数解析（@PathVariable/@RequestBody）全自动，写接口只剩业务逻辑
  2. 组件可插拔：HandlerMapping、ViewResolver、ExceptionResolver 全是接口，不满意就换——前后端分离就是跳过 ViewResolver 直接走 HttpMessageConverter 序列化 JSON
  3. 与 IOC 无缝：Controller 本身是 Bean，能注入 Service、能被 AOP 增强（接口耗时统计直接切 Controller 层）

2026 现状：前后端分离后 MVC 主要做 JSON API；Boot 3.x 底层已切到 jakarta.servlet 包名；性能上，阻塞模型配合虚拟线程（spring.threads.virtual.enabled=true）重新焕发活力，很多原来考虑 WebFlux 的吞吐场景现在用"MVC + 虚拟线程"就够了。