Appearance
过滤器和拦截器的区别：别再把它们当成同一层能力
Filter 和 Interceptor 经常一起出现，所以很多人会把它们简单理解成“都能拦请求”。
但如果把层次放清楚，你会发现它们根本不是同一层的东西。
先说结论
Filter属于 Servlet 规范体系的一部分Interceptor是 Spring MVC 提供的机制
更直白一点：
Filter更靠近 Web 容器Interceptor更靠近 Spring MVC 的处理流程
Filter 是什么
Filter 是 Java Web 里的标准组件之一，和 Servlet、Listener 一样，都属于 Servlet 规范。
它的特点是：
- 请求进入应用后，可以先经过 Filter
- 响应返回客户端前，也可以再经过 Filter
- 它不依赖 Spring MVC 才能存在
所以像下面这些事情，很适合用 Filter：
- 字符编码处理
- 跨域处理
- 请求日志基础记录
- 统一包装 request / response
- 对所有进入 Web 容器的请求做最外层控制
Interceptor 是什么
Interceptor 是 Spring MVC 提供的拦截机制，用来拦截由 DispatcherServlet 分发的处理流程。
它的特点是：
- 依赖 Spring MVC
- 作用对象是 Handler 执行链
- 更容易拿到 Spring 上下文和业务相关信息
所以这些事情更适合用 Interceptor：
- 登录检查
- 权限控制
- 接口耗时统计
- 基于用户上下文的通用预处理
- 某类控制器请求的统一逻辑
两者最大的区别是什么
1. 所处层次不同
这是最核心的区别。
Filter在 Servlet 容器层Interceptor在 Spring MVC 层
所以不要再用“谁比谁更高级”这种思路去理解，它们解决的问题不是完全一样的。
2. 依赖关系不同
Filter不依赖 Spring MVCInterceptor必须依赖 Spring MVC
如果一个请求压根没进入 DispatcherServlet 的处理链，那么 Interceptor 就不会生效，但 Filter 仍然有可能生效。
3. 可拿到的上下文不同
Interceptor 更容易拿到 Spring 体系里的对象和上下文，例如：
- Handler 信息
- Controller 方法
- Spring Bean
- 当前业务上下文
而 Filter 更偏原始的 HTTP 请求响应处理。
4. 使用场景不同
如果你只是想对所有请求做最外层处理，优先考虑 Filter。
如果你已经明确是在 Spring MVC 业务链路里处理请求，优先考虑 Interceptor。
执行时机怎么理解
可以简单理解成这样：
- 请求先进 Filter
- 再进入 Spring MVC
- 进入 Handler 之前会经过 Interceptor
- 处理完成后再按链路返回
所以在很多场景里，Filter 比 Interceptor 更靠外层。
常见使用建议
更适合用 Filter 的场景
- 字符编码设置
- XSS / 请求包装
- 跨域基础处理
- 请求链最外层统一日志
更适合用 Interceptor 的场景
- 登录校验
- 权限校验
- 接口耗时统计
- 用户上下文注入
- 业务相关通用逻辑
一个容易过时的说法
很多旧资料会写：
拦截器只对 action 起作用。
这个说法带着比较明显的早期 MVC 框架背景。放在现在的 Spring MVC 语境里，更准确的表达应该是：
Interceptor主要拦截由 Spring MVC Handler 处理的请求。
这样更贴近现在的实际工程场景。
一句话总结
如果你只想记一句最实用的话，可以记这个：
Filter解决的是“进入 Web 容器时的通用处理”，Interceptor解决的是“进入 Spring MVC 业务链路后的通用处理”。
这两个能力并不冲突，很多项目里本来就会同时使用。