Spring MVC 全面详解（Java 主流 Web 开发框架）

优质文章学习记录

— 14 min read

Spring MVC 全面详解（Java 主流 Web 开发框架）

一、Spring MVC 是什么 & 定位

Spring MVC 是 Spring Framework 框架的核心模块之一，是一款基于MVC 设计模式的轻量级 Java Web 开发框架，也是目前 Java 后端主流的 Web 开发技术（没有之一）。

价值：简化 Java Web 开发，将 Web 开发中的「请求接收、参数封装、业务处理、响应返回」等流程标准化、解耦化；

理念：遵循 约定优于配置 + 面向接口编程，兼顾灵活性和开发效率；

特性：原生兼容 Spring 生态（IoC、AOP）、轻量无侵入、组件化可插拔、支持 RESTful 风格、请求映射灵活、数据绑定强大。

二、先搞懂：MVC 设计模式（Spring MVC 的基础）

Spring MVC 的本质是对 MVC 设计模式的完美落地实现，想要理解 Spring MVC，必须先理解 MVC，MVC 是所有 Web 开发的经典分层思想，和语言无关：

MVC 三个核心角色（职责完全分离，解耦核心）

  1. M - Model（模型层）核心作用：封装数据 + 业务逻辑处理包含内容：实体类（POJO/Entity，比如 User、Order）、Service 业务层、Dao 持久层（操作数据库）；核心职责：只关注数据和业务，不关心前端页面如何展示、请求如何传递，是纯 Java 逻辑层。
  2. V - View（视图层）核心作用：数据展示，给用户呈现最终的结果包含内容：传统的 JSP、HTML 页面、Freemarker/Thymeleaf 模板、Vue/React 前端页面等；核心职责：只负责把 Model 层传递过来的数据渲染成可视化页面，不做任何业务逻辑处理。
  3. C - Controller（控制层）核心作用：请求调度的核心，承上启下，Spring MVC 的核心层核心职责：接收前端浏览器发送的 HTTP 请求（GET/POST 等）；调用 Model 层的业务方法处理请求；将业务处理后的结果（Model 数据）传递给 View 层；控制页面跳转或直接返回 JSON 数据。

MVC 核心优势

彻底解耦：三层职责单一，互不依赖。比如修改页面样式（View），完全不用改业务代码（Model）；修改业务逻辑（Model），控制层（Controller）只需要调用对应方法即可，极大提升项目的可维护性和扩展性。

三、Spring MVC 的核心架构 & 执行流程

Spring MVC 是一个请求驱动的框架，所有请求都遵循「统一入口，统一出口」的标准化流程

前提

Spring MVC 的所有请求，都会经过一个 唯一的核心前端控制器 —— DispatcherServlet，它是整个 Spring MVC 的「总指挥」，所有请求的分发、调度都由它完成，开发者无需编写任何代码，只需在配置文件中配置即可。

Spring MVC 完整的请求执行流程（10 步标准流程，从请求到响应）

  1. 客户端（浏览器 / Postman）发送 HTTP 请求 到 Web 服务器（Tomcat）；
  2. Web 服务器将请求转发给 Spring MVC 的核心控制器 DispatcherServlet（统一入口）；
  3. DispatcherServlet 收到请求后，调用 处理器映射器 HandlerMapping；
  4. HandlerMapping 根据请求的「URL 地址 + 请求方式」，匹配对应的 处理器 Handler（本质就是我们写的 Controller 类），并返回处理器执行链（包含 Handler 和拦截器）给 DispatcherServlet；
  5. DispatcherServlet 调用 处理器适配器 HandlerAdapter；
  6. HandlerAdapter 适配并执行对应的 Handler（Controller），在 Controller 中：接收并封装请求参数；调用 Service 层的业务方法处理请求；处理完成后，返回 ModelAndView 对象（包含：业务数据 Model + 视图地址 View）；
  7. HandlerAdapter 将执行结果（ModelAndView）返回给 DispatcherServlet；
  8. DispatcherServlet 调用 视图解析器 ViewResolver；
  9. ViewResolver 根据 ModelAndView 中的「视图地址」，解析出对应的 视图对象 View（比如 JSP/HTML）；
  10. DispatcherServlet 将 Model 中的数据渲染到 View 中，生成最终的响应页面，通过 Web 服务器返回给客户端，请求结束。
记忆：前端控制器是核心，所有组件都由它调度，开发者只需要写 Controller 和业务逻辑，其余组件 Spring MVC 都已内置实现。

四、Spring MVC 核心组件（各司其职，缺一不可）

上面流程中提到的组件，是 Spring MVC 的核心，全部由 Spring 容器管理，大部分组件开发者无需自定义，Spring 提供默认实现，这里讲清楚每个组件的核心作用：

1. 前端控制器：DispatcherServlet（核心核心核心）

地位：整个 Spring MVC 的核心，无它不成立；

作用：统一接收请求、统一响应结果，负责调度其他所有组件，相当于「交通指挥中心」；

特点：全局唯一，由开发者在 web.xml 或配置类中配置，生命周期由 Tomcat 管理。

2. 处理器映射器：HandlerMapping

作用：根据请求 URL 匹配对应的 Controller 方法；

原理：Spring 启动时，会扫描所有 Controller 中的请求映射注解（如 @RequestMapping），将「URL-Controller 方法」的映射关系存入内存，请求来时直接匹配。

常用实现：RequestMappingHandlerMapping（Spring MVC 默认，支持 @RequestMapping 系列注解）。

3. 处理器适配器：HandlerAdapter

作用：适配并执行 Handler（Controller）；

核心价值：屏蔽不同 Handler 的执行差异，让 DispatcherServlet 无需关心具体的 Controller 是如何执行的，只需要调用适配器即可，符合「开闭原则」。

常用实现：RequestMappingHandlerAdapter（Spring MVC 默认，适配 @RequestMapping 注解的 Controller）。

4. 处理器：Handler（开发者核心编写）

本质：就是我们编写的 Controller 类；

作用：业务请求的具体处理者，负责接收参数、调用业务逻辑、返回处理结果；

特点：开发者自定义，是 Spring MVC 中唯一需要开发者编写核心逻辑的组件。

5. 视图解析器：ViewResolver

作用：解析视图地址，生成视图对象；

核心能力：拼接视图路径，比如开发者返回视图名index，视图解析器可以自动拼接前缀/WEB-INF/views/和后缀.jsp，最终得到完整路径/WEB-INF/views/index.jsp。

常用实现：InternalResourceViewResolver（默认，支持 JSP 解析）。

6. 视图：View

作用：渲染数据，生成响应页面；

类型：JSP、HTML、Thymeleaf 模板、PDF 等，只负责展示数据，不处理业务。

五、Spring MVC 核心注解（高频必用，必须掌握）

Spring MVC 基于注解驱动开发，完全摒弃了早期的 XML 配置方式，所有核心功能都通过注解实现，以下是开发中常用到的核心注解，按使用频率排序：

类级注解：@Controller

作用：标记一个 Java 类为 Spring MVC 的控制（Controller/Handler）；

核心特性：

被该注解标记的类，会被 Spring 容器扫描并实例化（纳入 IoC 容器）；

该类中的方法可以通过「请求映射注解」绑定 URL，接收前端请求；

配合@ResponseBody注解，可让 Controller 直接返回 JSON 数据（前后端分离项目必用）。

补：该注解标记的类，默认返回视图名称（跳转页面，比如 JSP/HTML），而非数据，通常用于传统前后端一体项目（需要跳转页面、渲染视图）

类级 + 方法级注解：@RequestMapping

作用：建立「URL 请求地址」和「Controller 方法」的映射关系；

核心用法：

加在类上：设置当前 Controller 的「请求前缀」，所有方法的 URL 都基于该前缀拼接；

加在方法上：设置当前方法的「请求路径」，结合类上的前缀，形成完整的请求 URL；

核心属性：

value/path：指定请求 URL（必填）；

method：指定请求方式（GET/POST/PUT/DELETE），如method = RequestMethod.GET；

params：限制请求必须携带指定参数才会匹配；

示例：

@RestController@RequestMapping("/user")// 类上：所有方法的URL前缀都是 /userpublicclassUserController{// 方法上：完整请求URL = /user/query，仅处理GET请求@RequestMapping(value ="/query", method =RequestMethod.GET)publicStringquery(){return"查询用户";}}

简化版请求注解（Spring4.3 + 新增，推荐优先使用）

是@RequestMapping的专用简化版，语义更清晰，开发中常用这些代替 @RequestMapping：

@GetMapping("url") → 等价于 @RequestMapping(value="url",method=RequestMethod.GET) → 处理 GET 请求（查询）；

@PostMapping("url") → 等价于 @RequestMapping(value="url",method=RequestMethod.POST) → 处理 POST 请求（新增）；

@PutMapping("url") → 处理 PUT 请求（修改）；

@DeleteMapping("url") → 处理 DELETE 请求（删除）；

核心响应注解：@ResponseBody

作用：将方法的返回值，直接转换为 JSON 格式的响应体，返回给前端；

核心特性：

加在方法上：当前方法返回 JSON，不跳转页面；

加在类上：当前 Controller 的所有方法都返回 JSON，无需逐个添加；

✨ 组合注解：@RestController = @Controller + @ResponseBody → 前后端分离项目的标配，标记的 Controller 所有方法都返回 JSON，不会跳转视图。

补：不加该注解时，方法返回值会被解析为「视图名称」（比如返回"index"会跳转 index.jsp 页面）；

加了该注解后，返回值就是纯数据，不再跳转页面；

搭配@Controller使用，适合「部分方法返回 JSON、部分方法跳转页面」的混合场景。

请求参数接收注解

用于在 Controller 方法中接收前端传递的参数，开发中高频使用：

1.@RequestParam

@RequestParam("参数名")：接收URL 拼接参数（GET）或表单提交参数（POST），如@RequestParam("name") String username；

属性：

value/name：必填，指定前端传递的参数名，必须和前端一致；

required：可选，默认true，表示该参数必须传递，不传则报错；设为false则参数可选；

defaultValue：可选，给参数设置默认值，当参数未传递 / 传递空值时生效。

示例：

// 请求URL：http://localhost:8080/user/query?name=张三&age=20@GetMapping("/query")// 接收name和age参数，age可选，默认值18publicStringquery(@RequestParam("name")String username,@RequestParam(value ="age", required =false, defaultValue ="18")Integer age){return"姓名："+username+",年龄："+age;}

若：后端参数名 = 前端参数名，可以省略注解，直接写参数即可，底层自动映射：

// 等价于上面的写法，name和前端参数名一致，可省略@RequestParampublicStringquery(String name,Integer age){...}
2.@PathVariable

@PathVariable("占位符")：接收RESTful 风格的 URL 路径参数，如@GetMapping("/user/{id}")中，用@PathVariable("id") Integer id接收；

注意：

URL 中需要用 {参数名} 定义占位符；

注解的value值必须和占位符的参数名一致；

该参数默认是必传的，不传则请求 404。

// 请求URL：http://localhost:8080/user/1001/info@GetMapping("/{userId}/info")// {userId}是路径占位符publicStringgetUserInfo(@PathVariable("userId")String id){return"用户ID："+id;}
3.@RequestBody

@RequestBody：接收前端传递的 JSON 格式请求体（POST/PUT 必用），直接封装到实体类中，如@RequestBody User user；

特点：

只能标注在方法参数上，且一个方法只能有一个 @RequestBody 参数；

前端必须将参数放在 请求体 (Request Body) 中，且请求头Content-Type = application/json；

Spring MVC 会通过 Jackson 框架自动完成「JSON 字符串 → Java 对象」的反序列化，无需手动解析；

适用于传递复杂参数（比如新增用户时传递姓名、年龄、手机号、地址等多个字段）。

示例：

// 前端POST请求，请求体是JSON：{"name":"张三","age":20,"phone":"13800138000"}@PostMapping("/add")// 自动将JSON请求体封装为User实体类对象publicStringaddUser(@RequestBodyUser user){return"新增用户："+user.getName();}
4.@RequestHeader

作用：接收前端在 HTTP 请求头 中传递的参数，比如token、Content-Type、User-Agent等。

示例：

// 接收请求头中的token参数，用于接口鉴权@GetMapping("/auth")publicStringauth(@RequestHeader("token")String token){return"请求头中的令牌："+token;}
5.@CookieValue

作用：接收前端浏览器在请求中携带的 Cookie 数据，比如登录后的 Cookie 令牌。

@GetMapping("/cookie")publicStringgetCookie(@CookieValue("JSESSIONID")String sessionId){return"Cookie中的会话ID："+sessionId;}

补：

@ModelAttribute

作用：将前端传递的表单参数，自动封装为 Java 实体类对象，适用于传统表单提交的场景；

场景：替代多个@RequestParam，简化表单参数的封装，比如提交用户信息时，直接封装为User对象。

@CrossOrigin

作用：解决前端跨域请求问题，前后端分离项目必用！

使用：标注在 Controller 类上（所有方法允许跨域）或方法上（仅当前方法允许跨域），无需额外配置跨域过滤器，开箱即用。

示例：

@RestController@RequestMapping("/user")@CrossOrigin// 所有方法允许跨域请求publicclassUserController{...}

六、Spring MVC 最简入门示例（完整可运行，核心代码）

下面给出基于注解的最简 Spring MVC 入门案例，包含核心配置 + 核心代码，能直观看到 Spring MVC 的开发方式，分「传统前后端一体」和「前后端分离（主流）」两种最常用场景。

环境前提

JDK 8+

Spring MVC 5.x+

依赖：核心依赖spring-webmvc

✅ 场景 1：前后端分离（主流）→ 返回 JSON 数据（推荐）

1. 编写核心控制器（@RestController 版）
// 组合注解：@Controller + @ResponseBody，所有方法返回JSON@RestController// 类级请求前缀：所有方法的URL都以 /user 开头@RequestMapping("/user")publicclassUserController{// 处理GET请求，完整URL：http://localhost:8080/user/info/1@GetMapping("/info/{id}")publicUsergetUserInfo(@PathVariable("id")Integer id){// 模拟业务逻辑：根据ID查询用户User user =newUser(); user.setId(id); user.setName("张三"); user.setAge(20);// 直接返回实体类，Spring MVC自动转为JSON响应给前端return user;}// 处理POST请求，接收前端JSON参数，完整URL：http://localhost:8080/user/add@PostMapping("/add")publicResultaddUser(@RequestBodyUser user){// 模拟新增用户业务System.out.println("新增用户："+ user);// 返回统一响应结果returnResult.success("新增用户成功");}}// 实体类：UserclassUser{privateInteger id;privateString name;privateInteger age;// getter/setter 省略}// 统一响应结果类：ResultclassResult{privateInteger code;privateString msg;privateObject data;// 静态工具方法：success/error 省略}

✅ 场景 2：传统前后端一体 → 跳转页面（返回视图）

// 只加@Controller，方法返回视图名称，不是JSON@Controller@RequestMapping("/page")publicclassPageController{// 处理GET请求，URL：http://localhost:8080/page/index@GetMapping("/index")publicModelAndViewindex(){// 创建ModelAndView对象，封装数据+视图地址ModelAndView mv =newModelAndView();// 1. 往Model中存数据（前端页面可以获取） mv.addObject("msg","欢迎使用Spring MVC");// 2. 设置视图名称，视图解析器会拼接前缀+后缀 mv.setViewName("index");// 最终视图路径：/WEB-INF/views/index.jspreturn mv;}}

七、Spring MVC 的核心优势（为什么是 Java Web 的首选）

  1. 无缝集成 Spring 生态：Spring MVC 是 Spring 的核心模块，天然兼容 Spring 的 IoC 容器、AOP、事务管理、注解驱动等特性，无需额外整合，开发无缝衔接；
  2. 极致解耦：基于 MVC 设计模式，三层职责分离，代码可读性、可维护性、扩展性极强；
  3. 轻量级无侵入：核心依赖少，项目启动快，注解驱动开发，对业务代码几乎无侵入；
  4. 功能强大且灵活：支持 RESTful 风格、文件上传下载、拦截器、异常统一处理、数据校验、跨域请求等所有 Web 开发必备功能；
  5. 高性能：底层设计简洁，没有多余的封装，请求处理效率高，能支撑高并发场景；
  6. 社区成熟：Spring 生态是 Java 后端的事实标准，文档齐全、问题解决方案多，几乎所有 Java 后端岗位都要求掌握。

总结

  1. Spring MVC 是Spring 的核心模块，基于 MVC 设计模式的轻量级 Java Web 框架，Java Web 开发的主流技术；
  2. MVC 三层：Model（数据 + 业务）、View（展示）、Controller（调度），核心是解耦；
  3. Spring MVC 的核心是 DispatcherServlet（前端控制器），所有请求统一入口，调度其他组件；
  4. 核心执行流程：请求→DispatcherServlet→HandlerMapping→HandlerAdapter→Controller→ModelAndView→ViewResolver→View→响应；
  5. 核心注解：@Controller/@RestController、@RequestMapping及简化版@GetMapping/@PostMapping、@ResponseBody、@RequestParam/@PathVariable/@RequestBody；
  6. 主流开发方式：前后端分离，用@RestController返回 JSON，是目前企业开发的标配；
  7. 核心优势：无缝集成 Spring、极致解耦、轻量灵活、功能强大、社区成熟。

Read more

Flutter 三方库 discord_interactions 的鸿蒙化适配指南 - 在 OpenHarmony 打造高效的社交机器人交互底座

Flutter 三方库 discord_interactions 的鸿蒙化适配指南 - 在 OpenHarmony 打造高效的社交机器人交互底座

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 discord_interactions 的鸿蒙化适配指南 - 在 OpenHarmony 打造高效的社交机器人交互底座 在现代社交应用与办公协同工具的开发中，集成强大的机器人（Bot）交互能力是提升活跃度的关键。discord_interactions 库为 Flutter 开发者提供了一套完整的、遵循 Discord 官方协议的交互模型，涵盖了从 Slash Commands（斜杠命令）到 Webhook 签名验证的核心功能。本文将深入解析如何在 OpenHarmony（鸿蒙）环境下，结合鸿蒙的安全机制与网络特性，完美适配 discord_interactions 到你的鸿蒙应用中。 前言 随着鸿蒙系统（HarmonyOS）进入原生应用开发的新纪元，跨平台社交工具的适配需求日益增长。discord_interactions 作为一个纯

Windows 10/11环境下USB-Blaster驱动安装详解

USB-Blaster驱动在Win10/Win11下的“玄学”安装？一文彻底讲透！ 你有没有遇到过这样的场景： FPGA代码写完，板子上电正常，Quartus Prime也打开了——结果点“Program”时弹出红字警告：“ No hardware available ”。 设备管理器里多了一个黄色感叹号的“未知设备”，或者干脆显示“USB-Blaster [Invalid]”。 别急，这几乎每个用Altera（现Intel FPGA）开发的人都踩过的坑。问题不在你的代码，也不在硬件，而是在那个看似简单、实则暗藏玄机的 USB-Blaster 驱动安装 。 尤其是在 Windows 10 和 Windows 11 系统下，微软对驱动签名和内核安全越来越“较真”，传统的“插上去自动识别”早已成为过去式。今天我们就来把这件事从根儿上说清楚：为什么装不上？怎么才能稳稳地装上？以及那些官方文档不会告诉你的实战技巧。 不是所有“USB下载线”

Clawdbot Web Chat平台入门指南：Qwen3-32B模型参数微调后接入全流程

Clawdbot Web Chat平台入门指南：Qwen3-32B模型参数微调后接入全流程 1. 为什么需要这个平台？先说清楚你能得到什么 你是不是也遇到过这些问题：想快速验证一个大模型在自己业务场景下的真实效果，但又不想花几天时间搭环境、写接口、做前端；好不容易部署好了Qwen3-32B，却发现和聊天界面之间总差着一层“胶水”；或者团队里非技术人员想直接试用模型能力，却卡在命令行和API调用上？ Clawdbot Web Chat平台就是为解决这些实际问题而生的。它不是另一个需要从零编译、配置YAML、调试端口的复杂项目，而是一个开箱即用的轻量级Web对话入口——背后直连你已微调好的Qwen3-32B模型，所有通信走内部代理转发，不暴露原始服务，也不依赖公网域名或证书。 你不需要懂Ollama底层原理，不用改一行前端代码，更不用手动拼接HTTP请求头。只要你的Qwen3-32B模型已在本地通过Ollama运行起来，接下来只需三步：确认端口、配置代理、打开浏览器。5分钟内，你就能让产品经理、运营同事甚至客户，在一个干净的网页里，直接和你微调后的32B大模型对话。 这是一条真

Apache SeaTunnel Web 完整使用指南：从零搭建可视化数据集成平台

Apache SeaTunnel Web 完整使用指南：从零搭建可视化数据集成平台 【免费下载链接】seatunnel-webSeaTunnel is a distributed, high-performance data integration platform for the synchronization and transformation of massive data (offline & real-time). 项目地址: https://gitcode.com/gh_mirrors/se/seatunnel-web Apache SeaTunnel Web 是基于 SeaTunnel Connector API 和 Zeta Engine 开发的可视化管理平台，让数据集成工作变得前所未有的简单。无论您是数据工程师、开发人员还是运维人员，这个强大的 Web 控制台都能帮助您轻松管理海量数据的同步和转换任务。