Spring MVC 全面详解(Java 主流 Web 开发框架)

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 请求头 中传递的参数,比如tokenContent-TypeUser-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

Qwen3-VL-WEBUI在线教育:作业批改自动化部署解决方案

Qwen3-VL-WEBUI在线教育:作业批改自动化部署解决方案 1. 引言:在线教育中的作业批改痛点与技术革新 在当前快速发展的在线教育生态中,教师面临海量学生作业的批改任务,尤其是涉及图像、图表、手写公式甚至视频类内容时,传统文本型大模型难以胜任。人工批改耗时耗力,而现有自动化工具在多模态理解能力、复杂逻辑推理和跨模态对齐精度上存在明显短板。 阿里云最新开源的 Qwen3-VL-WEBUI 正是为解决这一核心痛点而生。它不仅集成了迄今为止最强大的视觉-语言模型 Qwen3-VL-4B-Instruct,还通过 WebUI 界面实现了“开箱即用”的本地化部署,特别适用于教育机构实现作业自动批改系统的轻量化落地。 本文将围绕 Qwen3-VL-WEBUI 在在线教育场景下的作业批改自动化部署方案展开,涵盖其技术优势、部署流程、实际应用案例及优化建议,帮助开发者和教育科技团队快速构建高效、精准的智能批改系统。 2. 技术背景:Qwen3-VL 的核心能力解析 2.1 Qwen3-VL 模型架构升级详解 作为 Qwen 系列的最新一代视觉语言模型,Qwen3-VL 在多个

DAMO-YOLO-S WebUI无障碍适配:屏幕阅读器支持与键盘导航优化

DAMO-YOLO-S WebUI无障碍适配:屏幕阅读器支持与键盘导航优化 1. 项目背景与意义 在现代Web应用开发中,无障碍访问(Accessibility)已经成为一个不可忽视的重要议题。DAMO-YOLO-S作为一个基于先进目标检测技术的手机检测系统,其Web界面的无障碍适配对于确保所有用户都能平等使用这一技术具有重要意义。 传统的计算机视觉应用往往忽视了视障用户和行动不便用户的需求。通过为DAMO-YOLO-S WebUI添加屏幕阅读器支持和键盘导航优化,我们不仅提升了产品的包容性,也为更多用户群体打开了使用先进AI技术的大门。 这项改进工作的核心价值在于: * 平等访问:确保视障用户能够通过屏幕阅读器理解界面内容和操作流程 * 操作便利:为无法使用鼠标的用户提供完整的键盘操作支持 * 合规性:符合Web内容无障碍指南(WCAG)标准要求 * 用户体验:为所有用户提供更加友好和高效的操作体验 2. 屏幕阅读器支持实现 2.1 ARIA标签优化 为DAMO-YOLO-S WebUI中的关键元素添加适当的ARIA(Accessible Rich Int

用 ASCII 草图 + AI 快速生成前端代码

引言 从想法到代码,中间往往要经历画原型、出设计稿等环节。 用 ASCII 草图,可以跳过大量原型绘制、结构拆解和手动搭骨架的中间步骤。 这种表达方式其实一直存在,但真正让它进入工程流程的,是 AI 的能力提升。大语言模型对结构化文本具有很强的解析能力,能够识别文本中的层级、对齐关系与空间划分,并将这些结构信息稳定地映射为组件树和页面布局。 因此,ASCII 不再只是沟通草稿,而成为一种可执行的结构描述。 什么是 “ASCII 草图” 提到 ASCII,很多人的第一反应可能是那个年代久远的“字符画”。没错,ASCII 草图就是用字符来构建页面布局。 在 AI 时代,这种看似简陋的草图,其实蕴含着巨大的能量。大语言模型(LLM)对结构化文本的理解能力极强。相比于模糊的自然语言描述(“我要一个左边宽右边窄的布局”),ASCII 草图提供了一种所见即所得的结构化 Prompt。 简单来说,ASCII 草图充当了视觉蓝图的角色,AI 根据这个结构生成代码。

WebGIS + 无人机 + AI:下一代智能巡检系统?

WebGIS + 无人机 + AI:下一代智能巡检系统?

WebGIS 遇上无人机,再叠加 AI 能力,巡检不再只是“看画面”,而是变成“智能决策系统”。 一、为什么 WebGIS + 无人机 + AI 是趋势? 在传统巡检场景中: * 电力巡检 → 人工拍照 * 工地巡查 → 人工记录 * 农业监测 → 靠经验判断 * 安防巡逻 → 事后回放 问题: * 数据无法实时分析 * 缺乏空间关联 * 没有智能预警能力 * 无法形成可视化决策系统 而结合: * WebGIS(三维可视化) * 无人机(数据采集) * AI(智能识别与分析) 我们可以构建: 一个真正的“空天地一体化智能巡检系统” 二、整体技术架构设计 1、系统分层架构 ┌──────────────────────────────┐ │ 前端可视化层 │ │ Cesium + Three.js + WebGL │ └──────────────┬───────────────┘ │ ┌──────────────▼───────────────┐ │ 业务中台层 │ │ AI推理