刚入行那几年我亲手搭过不下十个传统 Spring MVC 项目从建 web.xml、配 DispatcherServlet到写一堆 XML 和 Java Config再打 war 包扔到 Tomcat 下。后来 Spring Boot 出现我一度觉得“这玩意儿不就是把 Spring MVC 包了一层吗”直到被一个诡异的自动配置问题折磨了两天我才真正开始看懂两者的本质差异。这篇文章我结合自己的经历从配置、启动机制、依赖管理、部署方式、可观测性几个维度把两者的差异彻底聊透并附上关键源码佐证。一、一个简单的对比场景做一个 RESTful 接口传统 Spring MVC 时代要跑起来一个“Hello World”接口你需要创建 Maven 项目引入spring-webmvc、javax.servlet-api等依赖编写web.xml声明DispatcherServlet和映射路径编写 Spring MVC 配置文件开启注解驱动、组件扫描、视图解析器实现 Controller方法上打RequestMapping打包成 war部署到外部 Tomcat 启动Spring Boot 时代同样的需求用SpringBootApplication标注主类main方法写一行SpringApplication.run(…)Controller 上和传统 MVC 一模一样直接以 Java Application 方式启动内嵌 Tomcat 自动运行直观感受Spring Boot 砍掉了 80% 的“磨刀”时间。但程序员不能只停留在表面必须知道它到底砍掉了什么又可能埋了什么坑。二、核心差异一从 web.xml 到自动配置传统 Spring MVC 的核心入口是DispatcherServlet必须在web.xml中定义servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-value/WEB-INF/applicationContext.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern//url-pattern /servlet-mappingSpring Boot 里根本见不到这段配置因为它通过DispatcherServletAutoConfiguration自动完成了注册AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE) Configuration(proxyBeanMethods false) ConditionalOnWebApplication(type Type.SERVLET) ConditionalOnClass(DispatcherServlet.class) AutoConfigureAfter(ServletWebServerFactoryAutoConfiguration.class) public class DispatcherServletAutoConfiguration { Configuration(proxyBeanMethods false) ConditionalOnClass(ServletRegistration.class) EnableConfigurationProperties(WebMvcProperties.class) public static class DispatcherServletConfiguration { Bean ConditionalOnBean(MultipartResolver.class) public DispatcherServlet dispatcherServlet(WebMvcProperties webMvcProperties) { DispatcherServlet servlet new DispatcherServlet(); servlet.setDispatchOptionsRequest(webMvcProperties.isDispatchOptionsRequest()); // ... 一系列配置 return servlet; } } // 还有注册到 Servlet 容器的配置 }Spring Boot 基于“类是否存在”、“Bean 是否存在”、“配置属性值”等条件来判断该不该创建这些 Bean。这背后是Conditional系列的功劳。好处是你不用写模板代码坏处是如果你不理解自动配置的匹配规则就容易出现“Bean 莫名被覆盖”、“配置不生效”的问题。三、核心差异二依赖管理的进化——从“找包”到“Starter”传统 MVC 项目pom.xml 长这样xmldependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.3.22/version /dependency dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.13.3/version /dependency !-- 还需要配置 Jackson 的 MessageConverter不然返回 JSON 报406 --Spring Boot 只需一个 starterxmldependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency这一个 starter 帮你拉来了一整套经过版本测试的兼容包spring-webmvc、jackson、tomcat-embed、hibernate-validator 等。你甚至不需要写EnableWebMvc因为它已经在WebMvcAutoConfiguration里帮你加了并且默认注入了MappingJackson2HttpMessageConverter使得返回 JSON 开箱即用。我曾经在一个非 Boot 项目里手动集成 Jackson版本冲突调试了一下午。后来 Boot 的 starter 用久了再回看这种问题真有一种“刀耕火种”的感觉。四、核心差异三内嵌容器把部署模式彻底颠覆传统 MVC 的部署流程本地开发 → mvn package 打 war → 放到服务器 Tomcat 的 webapps 下 → 重启 Tomcat。我在生产环境搞过一次 Tomcat 调优改 server.xml 的线程池重启时停服务五分钟被运营盯着问。Spring Boot 把 Tomcat、Jetty、Undertow 内嵌进了应用启动类直接就是一个可执行的 jarSpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }背后的核心是ServletWebServerApplicationContext这个容器它在onRefresh()阶段会创建 WebServerOverride protected void onRefresh() { super.onRefresh(); try { createWebServer(); } catch (Throwable ex) { throw new ApplicationContextException(Unable to start web server, ex); } } private void createWebServer() { WebServer webServer this.webServer; ServletContext servletContext getServletContext(); if (webServer null servletContext null) { ServletWebServerFactory factory getWebServerFactory(); this.webServer factory.getWebServer(getSelfInitializer()); } // ... }这段代码意味着应用即服务器服务器即应用。部署时只需java -jar myapp.jar扩容就多启动一个进程。配合容器化和 K8s环境一致性极大提升。五、核心差异四外部化配置与环境迁移传统项目我们习惯把配置写在config.properties里然后通过PropertyPlaceholderConfigurer加载。不同环境放不同的文件dev.properties、prod.properties打包时人工替换经常出错。Spring Boot 的application-{profile}.yml配合spring.profiles.active参数做到了配置代码化、环境外置# application.yml server: port: 8080 --- spring: profiles: dev server: port: 8081 --- spring: profiles: prod server: port: 80启动时java -jar app.jar --spring.profiles.activeprod即可切换。更强大的是它支持环境变量、命令行参数、配置中心等优先级覆盖。我曾在 K8s 中把数据库密码放在 Secret 里通过环境变量注入Spring Boot 无缝接收完全不用改代码。六、表格化总结一张图看懂全部差异对比维度Spring MVC传统Spring Boot入口web.xml DispatcherServletmain方法 SpringBootApplication配置风格XML / Java Config 大量显式 Bean 定义自动配置 application.yml依赖管理手动引入易冲突starter 一站式版本仲裁服务器外部 Tomcat / Jetty独立部署内嵌容器应用自包含部署方式war 包 应用服务器Fat Jar java -jar监控需自行集成 Actuator 等Actuator 开箱即用健康检查、指标就绪学习曲线陡峭需理解 Servlet 规范、Spring 容器体系平缓新人一周可上手开发接口适用场景旧系统维护、需要定制 Servlet 容器行为的场景微服务、快速开发、容器化部署的首选七、不要误解Spring Boot 并没有取代 Spring MVC最后想澄清一个常见误解Spring Boot 并不是 Spring MVC 的替代品而是脚手架和集成器。当你在 Boot 项目里写RestController时底层依然是DispatcherServlet在干活依然是RequestMappingHandlerMapping在做路由映射。Boot 只是把搭建环境、连接各个组件这些脏活累活自动化了让你更专注于业务逻辑。但也正因为这种“黑盒”式的自动配置使用 Boot 的前提是必须深入理解 Spring MVC 本身。否则当自动配置不满足需求或者出现冲突时你只能抓瞎。只有真正理解底层原理的人才能不被框架束缚。一句话概括两者的关系Spring MVC 是一套精巧的乐器Spring Boot 是调好音准、连好音响、插上电即可演奏的舞台。要弹出好曲子乐器本身必须懂。
刚入行那几年我亲手搭过不下十个传统 Spring MVC 项目从建 web.xml、配 DispatcherServlet到写一堆 XML 和 Java Config再打 war 包扔到 Tomcat 下。后来 Spring Boot 出现我一度觉得“这玩意儿不就是把 Spring MVC 包了一层吗”直到被一个诡异的自动配置问题折磨了两天我才真正开始看懂两者的本质差异。这篇文章我结合自己的经历从配置、启动机制、依赖管理、部署方式、可观测性几个维度把两者的差异彻底聊透并附上关键源码佐证。一、一个简单的对比场景做一个 RESTful 接口传统 Spring MVC 时代要跑起来一个“Hello World”接口你需要创建 Maven 项目引入spring-webmvc、javax.servlet-api等依赖编写web.xml声明DispatcherServlet和映射路径编写 Spring MVC 配置文件开启注解驱动、组件扫描、视图解析器实现 Controller方法上打RequestMapping打包成 war部署到外部 Tomcat 启动Spring Boot 时代同样的需求用SpringBootApplication标注主类main方法写一行SpringApplication.run(…)Controller 上和传统 MVC 一模一样直接以 Java Application 方式启动内嵌 Tomcat 自动运行直观感受Spring Boot 砍掉了 80% 的“磨刀”时间。但程序员不能只停留在表面必须知道它到底砍掉了什么又可能埋了什么坑。二、核心差异一从 web.xml 到自动配置传统 Spring MVC 的核心入口是DispatcherServlet必须在web.xml中定义servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-value/WEB-INF/applicationContext.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern//url-pattern /servlet-mappingSpring Boot 里根本见不到这段配置因为它通过DispatcherServletAutoConfiguration自动完成了注册AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE) Configuration(proxyBeanMethods false) ConditionalOnWebApplication(type Type.SERVLET) ConditionalOnClass(DispatcherServlet.class) AutoConfigureAfter(ServletWebServerFactoryAutoConfiguration.class) public class DispatcherServletAutoConfiguration { Configuration(proxyBeanMethods false) ConditionalOnClass(ServletRegistration.class) EnableConfigurationProperties(WebMvcProperties.class) public static class DispatcherServletConfiguration { Bean ConditionalOnBean(MultipartResolver.class) public DispatcherServlet dispatcherServlet(WebMvcProperties webMvcProperties) { DispatcherServlet servlet new DispatcherServlet(); servlet.setDispatchOptionsRequest(webMvcProperties.isDispatchOptionsRequest()); // ... 一系列配置 return servlet; } } // 还有注册到 Servlet 容器的配置 }Spring Boot 基于“类是否存在”、“Bean 是否存在”、“配置属性值”等条件来判断该不该创建这些 Bean。这背后是Conditional系列的功劳。好处是你不用写模板代码坏处是如果你不理解自动配置的匹配规则就容易出现“Bean 莫名被覆盖”、“配置不生效”的问题。三、核心差异二依赖管理的进化——从“找包”到“Starter”传统 MVC 项目pom.xml 长这样xmldependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.3.22/version /dependency dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.13.3/version /dependency !-- 还需要配置 Jackson 的 MessageConverter不然返回 JSON 报406 --Spring Boot 只需一个 starterxmldependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency这一个 starter 帮你拉来了一整套经过版本测试的兼容包spring-webmvc、jackson、tomcat-embed、hibernate-validator 等。你甚至不需要写EnableWebMvc因为它已经在WebMvcAutoConfiguration里帮你加了并且默认注入了MappingJackson2HttpMessageConverter使得返回 JSON 开箱即用。我曾经在一个非 Boot 项目里手动集成 Jackson版本冲突调试了一下午。后来 Boot 的 starter 用久了再回看这种问题真有一种“刀耕火种”的感觉。四、核心差异三内嵌容器把部署模式彻底颠覆传统 MVC 的部署流程本地开发 → mvn package 打 war → 放到服务器 Tomcat 的 webapps 下 → 重启 Tomcat。我在生产环境搞过一次 Tomcat 调优改 server.xml 的线程池重启时停服务五分钟被运营盯着问。Spring Boot 把 Tomcat、Jetty、Undertow 内嵌进了应用启动类直接就是一个可执行的 jarSpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }背后的核心是ServletWebServerApplicationContext这个容器它在onRefresh()阶段会创建 WebServerOverride protected void onRefresh() { super.onRefresh(); try { createWebServer(); } catch (Throwable ex) { throw new ApplicationContextException(Unable to start web server, ex); } } private void createWebServer() { WebServer webServer this.webServer; ServletContext servletContext getServletContext(); if (webServer null servletContext null) { ServletWebServerFactory factory getWebServerFactory(); this.webServer factory.getWebServer(getSelfInitializer()); } // ... }这段代码意味着应用即服务器服务器即应用。部署时只需java -jar myapp.jar扩容就多启动一个进程。配合容器化和 K8s环境一致性极大提升。五、核心差异四外部化配置与环境迁移传统项目我们习惯把配置写在config.properties里然后通过PropertyPlaceholderConfigurer加载。不同环境放不同的文件dev.properties、prod.properties打包时人工替换经常出错。Spring Boot 的application-{profile}.yml配合spring.profiles.active参数做到了配置代码化、环境外置# application.yml server: port: 8080 --- spring: profiles: dev server: port: 8081 --- spring: profiles: prod server: port: 80启动时java -jar app.jar --spring.profiles.activeprod即可切换。更强大的是它支持环境变量、命令行参数、配置中心等优先级覆盖。我曾在 K8s 中把数据库密码放在 Secret 里通过环境变量注入Spring Boot 无缝接收完全不用改代码。六、表格化总结一张图看懂全部差异对比维度Spring MVC传统Spring Boot入口web.xml DispatcherServletmain方法 SpringBootApplication配置风格XML / Java Config 大量显式 Bean 定义自动配置 application.yml依赖管理手动引入易冲突starter 一站式版本仲裁服务器外部 Tomcat / Jetty独立部署内嵌容器应用自包含部署方式war 包 应用服务器Fat Jar java -jar监控需自行集成 Actuator 等Actuator 开箱即用健康检查、指标就绪学习曲线陡峭需理解 Servlet 规范、Spring 容器体系平缓新人一周可上手开发接口适用场景旧系统维护、需要定制 Servlet 容器行为的场景微服务、快速开发、容器化部署的首选七、不要误解Spring Boot 并没有取代 Spring MVC最后想澄清一个常见误解Spring Boot 并不是 Spring MVC 的替代品而是脚手架和集成器。当你在 Boot 项目里写RestController时底层依然是DispatcherServlet在干活依然是RequestMappingHandlerMapping在做路由映射。Boot 只是把搭建环境、连接各个组件这些脏活累活自动化了让你更专注于业务逻辑。但也正因为这种“黑盒”式的自动配置使用 Boot 的前提是必须深入理解 Spring MVC 本身。否则当自动配置不满足需求或者出现冲突时你只能抓瞎。只有真正理解底层原理的人才能不被框架束缚。一句话概括两者的关系Spring MVC 是一套精巧的乐器Spring Boot 是调好音准、连好音响、插上电即可演奏的舞台。要弹出好曲子乐器本身必须懂。
