很多人学习 Java Web，会直接从 Spring MVC 或 Spring Boot 开始。这在项目落地上当然没有问题，但如果完全不知道 Servlet 在解决什么问题，就很难真正理解一次 HTTP 请求在服务端到底经历了哪些阶段。框架只是把底层重复工作封装起来，并没有改变 Web 服务的基本模型。
所以这一节真正重要的，不是要求你以后都自己写原生 Servlet，而是先建立一条请求生命周期主线。只要这条主线清楚，后面看 Filter、Interceptor、Controller、统一异常处理、参数绑定这些能力时，都会更顺很多。
为什么理解 Servlet 不是“学老知识”？
因为它不是历史包袱，而是 Java Web 世界的基础抽象之一。哪怕你平时绝大多数时间都在写 Spring Boot，底层很多能力仍然站在 Servlet 这条模型上：
- 请求怎样进入应用；
- 请求和响应怎样被抽象成对象；
- 容器怎样把请求分发给处理逻辑；
- 过滤逻辑在哪一层发生；
- 响应怎样最终回写给客户端。
换句话说，Servlet 不等于“手写低级代码”，它是在帮你建立 Java Web 的最小模型。
一次请求到底经历了什么？
入门阶段最需要建立的不是 API 细节，而是顺序感。更简化地理解，一次请求通常会经历：
1. 客户端发起 HTTP 请求；2. Web 容器接收连接和请求数据；3. 请求经过外围过滤逻辑；4. 路由到具体处理器；5. 业务逻辑执行；6. 响应被组织和写回；7. 容器完成返回。
一旦你有了这条主线，再去理解不同框架为什么会设计出：
- Filter；
- Dispatcher；
- Interceptor；
- Controller；
- Exception Handler；
就不会觉得它们只是“很多层注解和回调”。
Filter、Servlet、Controller 各自在解决什么？
这几个概念最容易在学习过程中被混成一团。更实用的理解方式是：
- Filter 更偏外围统一处理，比如认证、日志、跨域、编码设置；
- Servlet 是更底层的请求处理入口抽象；
- 更高层框架里的 Controller，则是在 Servlet 之上做更细颗粒度的业务路由和参数绑定。
也就是说，它们不是互相替代关系，而是站在不同抽象层级处理同一条请求链。
理解这点以后，你在项目里遇到问题时就更容易判断：
- 某个问题应该在最外围统一处理；
- 某个问题应该在控制器层处理；
- 某个问题其实已经太晚了，不该等请求进入业务层才发现。
Spring 为什么会比原生模型更顺手？
因为它在 Servlet 这套底层模型之上，把很多高频重复工作做了更细致的抽象。比如：
- 路由映射；
- 参数绑定；
- 响应序列化；
- 校验协作；
- 全局异常处理；
- 统一扩展点组织。
Spring 并不是凭空创造了一套全新 Web 世界，而是在 Servlet 模型基础上，帮你把请求处理链组织得更清晰、扩展得更方便、使用得更一致。
理解这一点非常重要。否则很多人就会把 Spring 学成“注解大全”，但一到请求链上的真实问题，比如编码、跨域、过滤顺序、异常传播，就又说不清楚。
放到项目里，这层基础认知最常用在哪里？
真实项目里，这条基础主线会非常直接地帮助你判断这些问题：
- 统一鉴权应该放在哪一层；
- 请求日志在过滤器里做，还是在业务里做；
- 全局异常到底是框架异常、业务异常，还是请求链上的基础问题；
- 静态资源、文件下载、跨域和编码问题为什么不应该都丢进 Controller；
- 某个请求为什么还没到业务逻辑就已经失败了。
你会发现，这些问题如果没有请求生命周期心智，就很容易只能靠试错去猜。
最容易踩的坑
这部分最常见的问题通常包括：
- 只会跟着框架写注解，不知道请求先后经过了哪些层；
- 把所有逻辑都塞进 Controller；
- 不理解 Filter 和 Interceptor 的职责差异；
- 请求参数、编码、响应头出问题时，只会盲调配置；
- 以为 Spring 自己“神奇处理了一切”，忽略底层请求模型仍然存在。
总结
Servlet 到 Spring 这条主线真正要建立的，是 Java Web 的最小模型。只要你知道请求从哪里来、经过哪些层、在哪一层最适合处理什么问题，后面的 Spring MVC 和 Boot 就不会只剩注解堆砌，而会变成一条真正可理解、可治理的请求处理链。