```html

JavaWeb和Spring Boot的关系

很多人刚学Java后端时，会以为Spring Boot是JavaWeb的升级版，或者干脆把两者当成一回事。我最初也这么想，直到自己动手写了一个没有Spring Boot的Servlet项目，才彻底搞明白——它们根本不是替代关系，而是地基和精装房的关系。

JavaWeb是一套技术规范的总称。它包含Servlet、JSP、Filter、Listener、JDBC这些基础组件。你写一个最简单的登录功能，需要继承HttpServlet，重写doGet和doPost，在web.xml里配置URL映射，再手动管理数据库连接。整个过程像自己搬砖和水泥，盖出来的房子能住，但管线裸露，墙没刷漆。部署时还得把项目打成war包，扔进Tomcat的webapps目录。这种开发方式在2005年左右是主流，现在看很笨重，可它定义了Java Web应用的基本运行模型：请求→Servlet容器→业务代码→响应。

Spring Boot出现得晚得多。它2014年发布，核心目标不是取代JavaWeb，而是让基于Spring的JavaWeb开发变得几乎不用配置。我印象很深的一个对比：用传统Spring MVC写一个REST接口，要配DispatcherServlet、ContextLoaderListener、视图解析器、JSON转换器，至少三个XML文件。换成Spring Boot，你只需要在pom.xml里加一个spring-boot-starter-web，然后写一个带@RestController的类。启动类上加@SpringBootApplication，运行main方法，内嵌的Tomcat就起来了。没有web.xml，没有手动配Servlet，甚至不需要安装Tomcat。

这里有个细节容易被忽略：Spring Boot内嵌的Tomcat本身就是一个Servlet容器。它并没有抛弃JavaWeb的规范，而是把Servlet、Filter这些底层组件自动装配好了。你依然可以在Spring Boot里注册FilterRegistrationBean，或者实现ServletContextInitializer。换句话说，Spring Boot跑的还是JavaWeb那套东西，只是把配置和部署的脏活累活揽过去了。

那为什么有人觉得用了Spring Boot就不需要懂JavaWeb？因为Spring Boot的自动配置太顺滑了。你写一个@GetMapping，请求就能映射到方法；你返回一个对象，Jackson自动转成JSON。这背后是DispatcherServlet在干活，是HttpMessageConverter在转换。如果不懂Servlet的请求转发和重定向区别，不懂Filter和Interceptor的执行顺序，遇到跨域、会话、文件上传这些问题照样会卡住。我见过一个同事在Spring Boot里用response.getWriter()写中文乱码，查了半天，最后发现是没设characterEncoding——这跟十年前Servlet里遇到的问题一模一样。

另一个观察：Spring Boot并没有完全覆盖JavaWeb的所有场景。比如JSP，Spring Boot官方不推荐，内嵌Tomcat对JSP的支持也有限制。如果你维护一个老项目，里面全是JSP页面和web.xml，硬套Spring Boot会很别扭。反过来，新项目用Spring Boot，你几乎不会直接写HttpServlet，但Servlet规范里的HttpServletRequest、HttpServletResponse、HttpSession你天天在用。它们就像空气，看不见但离不开。

所以我的判断是：JavaWeb是根，Spring Boot是长出来的主干。学JavaWeb不是让你回去写web.xml，而是理解请求怎么进来、线程怎么分配、会话怎么保持。这些知识决定了你排查问题的深度。而Spring Boot是当下干活的工具，它让开发效率翻倍，但别把它当成黑盒。哪天自动配置失效了，或者需要自定义一个Servlet，你翻开的还是JavaWeb那本书。

最后说个具体案例。我参与过一个监控系统，需要拦截所有请求记录耗时。如果用纯JavaWeb，写一个Filter，在doFilter里前后加时间戳，配到web.xml就行。换成Spring Boot，同样写一个Filter，但要用@Component或者FilterRegistrationBean注册。代码几乎没变，变的是注册方式。你看，底层逻辑没动，只是外壳换了。这就是它们最真实的关系。