DispatcherServlet 是 Spring MVC 的核心前端控制器，也是整个框架的总调度中心，所有客户端的 Web 请求都会先经过它。它的工作流程是标准化的：首先拦截所有请求，通过 HandlerMapping 组件找到与请求路径匹配的 Controller 和处理方法；接着调用 HandlerAdapter 执行对应的业务方法，获取方法返回的模型数据和视图信息；然后将结果交给视图解析器解析出具体视图；最后渲染视图并将响应返回给客户端。它全权负责请求分发、流程调度，开发者无需关注底层流程，只需要编写 Controller 的业务逻辑即可，是 Spring MVC 的核心枢纽。
@Controller 是 Spring 的组件注解，专门用来标记Web 请求处理器类。容器启动时，Spring 会扫描标注了 @Controller 的类，将其实例化为 Bean 并纳入 IoC 容器管理。同时，这个类会被 HandlerMapping 识别为请求处理组件，类中搭配 @RequestMapping、@GetMapping 等路径注解的方法，会被注册成请求映射规则。当 DispatcherServlet 接收到请求后，会根据路径匹配到对应的 Controller 方法并执行。该注解的核心作用是将普通 Java 类转化为能处理 Web 请求的控制器，实现了请求与业务逻辑的解耦。
Spring MVC 处理表单提交非常简便，核心是数据自动绑定。前端表单的 input 标签 name 属性，需要和后端 Java 实体类的属性名保持一致。客户端提交表单请求后，DispatcherServlet 会将表单参数传递给 Controller 方法，Spring 会自动把表单数据封装到实体类对象中，也可以直接用基本类型接收单个参数。Controller 接收数据后进行业务处理，处理完成后可以返回视图或重定向。同时还能搭配校验注解做表单验证，通过 BindingResult 接收校验结果，不满足规则就返回错误提示，整个流程无需手动解析表单参数。
ModelAndView 是 Spring MVC 中封装模型数据和视图信息的统一对象，是 Controller 处理完请求后返回的核心载体。它包含两部分：Model 是模型数据，用来存放需要传递给前端页面的业务数据；View 是视图名称，比如 jsp、html 页面的名字，用来指定展示数据的页面。Controller 方法可以创建 ModelAndView 对象，往里面添加数据、设置视图名，然后返回给 DispatcherServlet。相比单独返回视图名，它能一次性封装数据和页面，适合需要同时传递数据和指定页面的场景，是早期 Spring MVC 最常用的返回值类型。
Spring MVC 的拦截器是针对 Controller 请求的增强组件，作用和过滤器类似，但更贴合 Spring 生态。它主要在请求进入 Controller 前、处理完成后、视图渲染前三个节点执行自定义逻辑，核心用途包括登录校验、权限控制、日志记录、请求参数预处理等。拦截器由 Spring 容器管理，可以直接注入 Bean 使用，能精准拦截指定路径的请求，还能获取 Controller 的方法信息。它不拦截静态资源，只针对 Controller 请求，相比原生 Filter，更适合在 Spring MVC 项目中做业务层的请求拦截和增强。
视图解析器是 Spring MVC 中负责解析视图名称的核心组件。Controller 方法返回的通常是简洁的视图名（比如 login、index），而非完整的页面路径，视图解析器的作用就是把这个逻辑视图名，拼接成完整的物理视图路径。它会配置前缀和后缀，比如前缀是 /WEB-INF/views/，后缀是.jsp，那么视图名 login 就会被解析为 /WEB-INF/views/login.jsp。DispatcherServlet 拿到解析后的完整路径，就可以渲染页面并返回给客户端，它简化了视图的配置，让 Controller 无需关注页面的具体存储位置。
路径变量是通过 **@PathVariable 注解 ** 获取的 URL 路径中的动态参数，是 RESTful 风格接口的核心。它将参数直接拼接在 URL 路径中，比如 / user /1，其中 1 就是用户 id 的路径变量。在 Controller 方法中，用 @PathVariable 绑定路径参数和方法形参，就能直接获取数值。它的主要用途是设计简洁的 REST 接口，替代传统的? 拼接参数的方式，让 URL 更直观、语义化，适合获取、修改、删除指定资源的接口场景，是 Spring MVC 实现 RESTful API 的必备注解。
@RequestParam 是用来获取 URL 请求参数或表单参数的注解，主要处理? 后面拼接的参数，比如 /user?name= 张三 &age=20。它可以绑定请求参数和 Controller 方法的形参，支持设置参数是否必填、默认值、参数别名等。如果前端参数名和后端形参名一致，可以省略该注解；如果不一致，就用它指定参数名。它主要用于接收简单类型的参数（字符串、数字等），是 Spring MVC 中最常用的参数接收注解，适合表单提交、普通 GET 请求的参数获取场景。
Spring MVC 提供了全局统一异常处理方案，核心是 @RestControllerAdvice/@ControllerAdvice + @ExceptionHandler 注解。我们创建一个全局异常处理类，标注 @RestControllerAdvice，然后针对不同的异常类型编写方法，用 @ExceptionHandler 指定要捕获的异常。当 Controller 抛出异常时，会被该类的对应方法捕获，统一封装错误信息返回给前端。此外还支持局部异常处理（Controller 内定义）、自定义异常解析器，这种方式将分散的异常逻辑集中管理，返回格式统一，方便排查问题，是企业项目的标准用法。
重定向和转发是 Spring MVC 中页面跳转的两种方式，核心区别很大。转发是服务器内部跳转，地址栏 URL 不变，一次请求，能共享 Request 域的数据，效率更高，适合页面内部跳转。重定向是客户端重新发起请求，地址栏 URL 会改变，两次请求，不能共享 Request 数据，会重新经过 DispatcherServlet。转发用 forward: 前缀，重定向用 redirect: 前缀。重定向适合表单提交后避免重复提交、跳转外部链接；转发适合内部页面快速跳转，日常开发根据业务场景选择即可。
Spring MVC 默认会拦截所有请求，导致无法访问 JS、CSS、图片等静态资源，因此需要专门配置静态资源映射。核心是通过 mvc:resources/ 标签（XML）或实现 WebMvcConfigurer 接口（注解），指定静态资源的存放路径和访问规则。比如配置访问路径 /res/**，映射到项目的 /resources/ 目录，当请求 /res/xxx.js 时，框架会自动去对应目录查找资源。配置后，DispatcherServlet 会放行静态资源请求，不再交给 Controller 处理，保证前端页面能正常加载样式、脚本和图片，是 Web 项目的必备配置。
Spring MVC 是Spring 的 Web 层子框架，专注处理 Web 请求、页面跳转，需要手动配置 DispatcherServlet、视图解析器、静态资源等大量内容，配置繁琐。Spring Boot 是快速开发框架，并非替代 Spring MVC，而是对 Spring 生态的封装，核心是约定大于配置。Spring Boot 自动配置好 Spring MVC 所需的所有组件，内置 Tomcat 服务器，无需手动 XML 配置，引入 starter-web 依赖就能直接开发 Web 接口。简单说，Spring MVC 是 Web 开发的核心，Spring Boot 是简化 Spring MVC 开发、部署的工具。
数据绑定是 Spring MVC自动将请求参数封装为 Java 对象的核心机制。客户端提交的表单参数、URL 参数都是字符串类型，Spring 会通过数据绑定器，将这些字符串自动转换为对应 Java 实体类的属性类型（数字、日期等），并封装成对象。绑定的前提是前端参数名和实体类属性名一致，框架通过反射找到对应的 setter 方法赋值。同时支持自定义类型转换器，处理特殊格式的参数。数据绑定省去了手动解析参数、封装对象的繁琐操作，大幅简化了 Controller 的参数接收工作。
Content Negotiation 叫内容协商，是 Spring MVC 根据客户端需求，返回不同格式数据的机制。客户端可以通过请求头、URL 后缀、参数等方式，告诉服务器需要的数据格式（JSON、XML、HTML 等）。Spring MVC 会根据客户端的要求，选择对应的消息转换器，将模型数据转换成指定格式返回。比如客户端请求.json 后缀，就返回 JSON 数据；请求.xml 就返回 XML 数据。它让同一个接口能适配不同客户端的需求，无需编写多个接口，提升了接口的通用性和扩展性。
@RequestBody 和 @ResponseBody 是处理 JSON 数据的核心注解。@RequestBody 用在 Controller 方法的形参上，将前端传来的 JSON 字符串自动解析为 Java 对象，解决了前端传递复杂 JSON 数据的接收问题。@ResponseBody 用在方法或类上，将方法返回的 Java 对象自动转换为 JSON 字符串，直接响应给前端，不再跳转页面。两个注解搭配使用，专门处理前后端分离的 AJAX 请求，是开发 RESTful API 的必备注解，让前后端数据交互更便捷。
三者都是用来传递数据到前端的载体，核心区别在使用方式。Model 是一个接口，只用来存放模型数据，通过 addAttribute 方法添加数据，返回值为视图名，使用最简洁。ModelMap 是 Map 的实现类，功能和 Model 一致，用法几乎相同，底层基于键值对存储数据，兼容 Map 的操作方法。ModelAndView 是数据 + 视图的封装对象，既可以添加数据，又能指定视图名称，一个对象完成所有操作。日常开发优先用 Model，简洁易用；需要同时指定视图和数据时用 ModelAndView，ModelMap 极少使用。
视图解析是 DispatcherServlet 将 Controller 返回的逻辑视图名，转为物理视图的完整流程。Controller 处理完请求后，返回逻辑视图名（如 index）；DispatcherServlet 将视图名交给 ViewResolver 视图解析器；解析器根据配置的前缀、后缀，拼接出完整的物理视图路径（如 /WEB-INF/views/index.jsp）；接着解析器创建 View 视图对象；最后 View 对象渲染页面，将 Model 中的数据填充到页面中，生成 HTML 响应返回给客户端。整个过程自动完成，开发者只需配置前缀后缀，无需关注底层解析细节。
前端控制器模式是 Spring MVC 的核心设计模式，属于通用的 Web 设计模式。该模式的核心是用一个统一的中央控制器（DispatcherServlet）接收所有客户端请求，统一处理请求分发、流程调度，而非每个请求对应一个独立的处理器。所有请求先经过中央控制器，再由它分发给具体的业务处理器（Controller）。这种模式统一了请求入口，简化了请求处理流程，实现了请求调度和业务逻辑的解耦，方便统一处理拦截、异常、日志等通用逻辑，是 Spring MVC 的架构基础。
两个注解都是用来操作 Session 域数据，用法不同。@SessionAttributes用在 Controller 类上，指定将 Model 中的哪些数据自动存入 Session 域，实现跨请求共享数据，适合在同一个控制器的多个方法间共享数据，比如表单分步提交。@SessionAttribute用在方法形参上，从 Session 域中获取已存在的数据，直接绑定到方法参数上，方便读取 Session 中的用户信息、登录状态等。两者搭配使用，简化了 Session 数据的存取操作，无需手动调用 request.getSession()，让代码更简洁。
WebApplicationContext 是 Spring MVC专用于 Web 环境的 IoC 容器，是 ApplicationContext 的子接口，具备普通容器的所有功能，还新增了 Web 相关特性。它和 Web 容器（Tomcat）绑定，生命周期随 Web 应用启动和销毁，能获取 ServletContext、请求、会话等 Web 对象。Spring MVC 中，会创建父子容器：父容器管理 Service、Dao 等业务 Bean，子容器（WebApplicationContext）管理 Controller、视图解析器、拦截器等 Web 组件。它是 Spring MVC 在 Web 环境中运行的核心容器，支撑了整个 Web 层的 Bean 管理。
@ModelAttribute 是 Spring MVC 的实用注解，有三种核心用法。一是用在方法上，该方法会在当前 Controller 的所有请求方法执行前运行，用来预加载数据到 Model 中，全局共享。二是用在方法形参上，自动将请求参数绑定到实体对象，并将对象存入 Model，前端可直接获取。三是配合 @SessionAttributes 使用，从 Session 中获取数据绑定到参数。它主要用于数据预加载、参数绑定、模型数据共享，是简化 Controller 数据处理的重要注解，适合需要全局共享数据的场景。
@RestController 是 @Controller 和 @ResponseBody 的组合注解，是专门为前后端分离开发设计的。标注 @Controller 的类是传统控制器，方法返回值默认是视图名，会跳转页面；如果要返回 JSON 数据，需要额外加 @ResponseBody。标注 @RestController 的类，所有方法默认都会将返回对象转为 JSON 格式，直接响应给前端，不会跳转页面。@Controller 适合传统的页面开发项目，@RestController 适合 RESTful API、前后端分离的微服务项目，是现代 Web 开发的主流选择。
HandlerMapping 是 Spring MVC 的核心组件，负责请求路径与 Controller 方法的映射匹配。容器启动时，它会扫描所有 Controller 的路径注解（@RequestMapping 等），建立路径和处理方法的映射关系表。当 DispatcherServlet 接收到客户端请求时，会交给 HandlerMapping，根据请求的 URL 查找对应的 Controller 和处理方法，找到后封装成 HandlerExecutionChain 对象返回。它是请求分发的关键，没有它，DispatcherServlet 就无法找到对应的业务处理器，是连接请求和 Controller 的桥梁。
Spring MVC 文件上传基于 Apache Commons FileUpload 或 Servlet3.0 原生上传，配置简单。首先引入文件上传依赖，然后在配置类中注册 MultipartResolver 文件上传解析器。前端表单设置 enctype="multipart/form-data"，用 input type="file" 选择文件。后端 Controller 方法用 MultipartFile 类型接收上传的文件，通过 getOriginalFilename()获取文件名，transferTo() 方法将文件保存到服务器指定目录。支持单文件和多文件上传，框架自动封装文件流，无需手动处理 IO 操作，大幅简化了文件上传的开发流程。
Spring MVC 的国际化支持多语言切换，核心是 LocaleResolver 和 MessageSource 组件。首先创建不同语言的配置文件（如中文、英文），存放对应语言的文案。MessageSource 加载这些配置文件，LocaleResolver 解析客户端的语言环境（从请求头、Session、Cookie 获取）。Controller 中通过 MessageSource 获取对应语言的文案，传递到前端页面。前端页面通过标签展示多语言文案，用户切换语言时，LocaleResolver 更新语言环境，自动加载对应配置文件，无需修改业务代码，快速适配多语言场景。
Spring MVC 异步请求用来解决高并发下的线程阻塞问题，提升服务器吞吐量。传统请求是同步的，一个请求占用一个线程直到处理完成。异步处理时，Controller 方法返回 Callable 或 DeferredResult 对象，Spring 会将业务逻辑交给新的线程执行，主线程立即释放，接收其他请求。业务线程处理完成后，会通知 Spring 容器返回响应。异步请求适合耗时操作（如调用第三方接口、批量处理数据），能有效利用服务器资源，提高高并发场景下的系统性能。
两者都是获取请求参数的注解，核心区别在参数位置和用途。@PathVariable 获取URL 路径中的动态参数，格式为 /user/{id}，是 RESTful 风格的参数，参数是 URL 的一部分，用于标识资源。@RequestParam 获取URL? 后拼接的参数，格式为 /user?id=1，用于过滤、查询资源。@PathVariable 适合获取资源唯一标识，@RequestParam 适合传递查询条件。两者不能混用，RESTful 接口优先用 @PathVariable，普通查询请求用 @RequestParam，是两种不同的参数传递规范。
Spring MVC 数据验证基于 JSR-380 校验规范（Hibernate Validator 实现），用来校验前端传递的参数合法性。在实体类的属性上添加校验注解（@NotBlank 非空、@Email 邮箱、@Length 长度等）。Controller 方法中，在实体类参数前加 @Valid 注解开启校验，并用 BindingResult 接收校验错误信息。如果校验不通过，BindingResult 会存储错误提示，后端可以将错误信息返回给前端。支持全局校验、分组校验，统一管理参数校验逻辑，避免在业务代码中编写大量的参数判断语句。
Spring MVC 是同步阻塞式Web 框架，基于 Servlet API，一个请求对应一个线程，开发简单、生态成熟，适合传统 Web 项目、中小型应用。Spring WebFlux 是异步非阻塞式响应式框架，基于 Reactor，少量线程就能处理高并发请求，靠事件驱动实现高吞吐，适合高并发、微服务、网关等场景。MVC 兼容所有传统组件，学习成本低；WebFlux 编程模型不同，生态组件较少。常规业务开发用 Spring MVC，追求高并发、高性能的场景用 Spring WebFlux。
Flash 属性是 Spring MVC 中跨重定向请求传递数据的解决方案，用 RedirectAttributes 对象实现。重定向是两次请求，Request 域的数据会丢失，无法传递提示信息（如“提交成功”）。Flash 属性会将数据临时存放在 Session 中，重定向后的请求获取到数据后，立即清除，保证数据只使用一次。它专门解决重定向时的数据传递问题，适合表单提交后重定向到列表页，并展示成功 / 失败提示信息的场景，无需手动操作 Session，使用简洁安全。
约定优于配置是 Spring MVC 的简化开发原则，核心是框架预设通用的配置规则，开发者无需手动配置，遵循约定即可开发。比如约定 Controller 放在 controller 包、视图放在 views 目录、表单参数名对应实体类属性名、请求路径匹配注解值等。框架按照这些默认约定自动处理逻辑，减少了 XML 或注解的配置量。如果需要特殊需求，再自定义配置。该原则大幅降低了开发门槛，让开发者专注业务逻辑，而非繁琐的配置，是 Spring MVC 易用性的核心体现。
三者是 Spring MVC 的核心组件，交互流程清晰。客户端发送请求，Controller（控制器） 接收请求，调用 Service 层处理业务逻辑，将处理结果存入Model（模型） 中，同时指定要展示的View（视图）。Controller 将 Model 和 View 返回给 DispatcherServlet，Servlet 通过视图解析器找到 View 页面。最后View（视图） 从 Model 中取出数据，渲染成 HTML 页面返回给客户端。Controller 负责处理请求和业务调度，Model 负责存储数据，View 负责展示数据，三者分离，实现了业务逻辑、数据、页面的解耦。
