blocks|key|1689841|text|来自HandlerIntercepter的javadoc|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1689842|Servlet+HandlerInterceptor基本上类似于Servlet+Filter，但与后者不同的是，它只允许自定义预处理，并允许禁止执行处理程序本身和自定义后处理。过滤器更强大，例如，它们允许交换传递到链上的请求和响应对象。请注意，过滤器是在应用程序上下文中的HandlerInterceptor+web.xml中配置的。|1689843|作为基本指导原则，与处理程序相关的细粒度预处理任务是HandlerInterceptor实现的候选任务，尤其是分解出来的通用处理程序代码和授权检查。另一方面，Filter非常适合请求内容和视图内容的处理，比如多部分表单和GZIP压缩。这通常会显示需要将过滤器映射到特定内容类型(例如图像)或所有请求的时间。|1689844|1689845|如上所述：|1689846|1689847|那么Interceptor#postHandle()和Filter#doFilter()的区别在哪里呢？|blockquote|1689848|1689849|1689850|postHandle将在处理程序方法调用之后但在呈现视图之前调用。因此，您可以向视图中添加更多的模型对象，但您不能更改HttpServletResponse，因为它已经提交了。|1689851|与postHandle相比，doFilter的功能要多得多。您可以更改请求或响应，并将其传递到链，甚至阻塞请求处理。|1689852|此外，在preHandle和postHandle方法中，您可以访问处理请求的HandlerMethod。因此，您可以根据处理程序本身添加预处理/后处理逻辑。例如，您可以为具有一些注释的处理程序方法添加逻辑。|1689853|1689854|在哪些用例中应该使用它的最佳实践是什么？|1689855|1689856|1689857|正如文档所说，与处理程序相关的细粒度预处理任务是HandlerInterceptor实现的候选任务，特别是分解出来的通用处理程序代码和授权检查。另一方面，Filter非常适合请求内容和视图内容的处理，比如多部分表单和GZIP压缩。这通常会显示需要将过滤器映射到特定内容类型(例如图像)或所有请求的时间。|1689858|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.spring.io/autorepo/docs/spring/current/javadoc-api/org/springframework/web/servlet/HandlerInterceptor.html^0|2|I|L|7|0|0|8|I|14|6|3S|I|4B|7|0|Q|I|27|6|0|0|0|0|2|O|R|H|0|0|0|0|A|1N|J|0|1|A|E|8|0|4|9|E|A|12|D|0|0|0|0|0|O|I|25|6|0^^$0|@$1|2|3|4|5|6|7|1D|8|@$9|1E|A|1F|B|C]]|D|@$9|1G|A|1H|1|1I]]|E|$]]|$1|F|3|G|5|6|7|1J|8|@$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]|$9|1O|A|1P|B|C]|$9|1Q|A|1R|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1S|8|@$9|1T|A|1U|B|C]|$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1X|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|1Y|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|N|3|O|5|P|7|20|8|@$9|21|A|22|B|C]|$9|23|A|24|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|25|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|26|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|27|8|@$9|28|A|29|B|C]|$9|2A|A|2B|B|C]]|D|@]|E|$]]|$1|U|3|V|5|6|7|2C|8|@$9|2D|A|2E|B|C]|$9|2F|A|2G|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|2H|8|@$9|2I|A|2J|B|C]|$9|2K|A|2L|B|C]|$9|2M|A|2N|B|C]]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|2O|8|@]|D|@]|E|$]]|$1|Z|3|10|5|P|7|2P|8|@]|D|@]|E|$]]|$1|11|3|-4|5|6|7|2Q|8|@]|D|@]|E|$]]|$1|12|3|-4|5|6|7|2R|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|2S|8|@$9|2T|A|2U|B|C]|$9|2V|A|2W|B|C]]|D|@]|E|$]]|$1|15|3|-4|5|6|7|2X|8|@]|D|@]|E|$]]]|16|$17|$5|18|19|1A|E|$1B|1C]]]]

From <code>HandlerIntercepter</code>'s <a href="http://docs.spring.io/autorepo/docs/spring/current/javadoc-api/org/springframework/web/servlet/HandlerInterceptor.html" rel="noreferrer">javadoc</a>:

<blockquote>
 <code>HandlerInterceptor</code> is basically similar to a Servlet <code>Filter</code>, but in
 contrast to the latter it just allows custom pre-processing with the
 option of prohibiting the execution of the handler itself, and custom
 post-processing. Filters are more powerful, for example they allow for
 exchanging the request and response objects that are handed down the
 chain. Note that a filter gets configured in <code>web.xml</code>, a
 <code>HandlerInterceptor</code> in the application context.
 
 As a basic guideline, fine-grained handler-related pre-processing tasks
 are candidates for <code>HandlerInterceptor</code> implementations, especially
 factored-out common handler code and authorization checks. On the
 other hand, a <code>Filter</code> is well-suited for request content and view
 content handling, like multipart forms and GZIP compression. This
 typically shows when one needs to map the filter to certain content
 types (e.g. images), or to all requests.
</blockquote>

With that being said:

<blockquote>
 So where is the difference between <code>Interceptor#postHandle()</code> and
 <code>Filter#doFilter()</code>?
</blockquote>

<code>postHandle</code> will be called after handler method invocation but before the view being rendered. So, you can add more model objects to the view but you can not change the <code>HttpServletResponse</code> since it's already committed.

<code>doFilter</code> is much more versatile than the <code>postHandle</code>. You can change the request or response and pass it to the chain or even block the request processing.

Also, in <code>preHandle</code> and <code>postHandle</code> methods, you have access to the <code>HandlerMethod</code> that processed the request. So, you can add pre/post-processing logic based on the handler itself. For example, you can add a logic for handler methods that have some annotations.

<blockquote>
 What is the best practise in which use cases it should be used?
</blockquote>

As the doc said, fine-grained handler-related pre-processing tasks are candidates for <code>HandlerInterceptor</code> implementations, especially factored-out common handler code and authorization checks. On the other hand, a <code>Filter</code> is well-suited for request content and view content handling, like multipart forms and GZIP compression. This typically shows when one needs to map the filter to certain content types (e.g. images), or to all requests.

blocks|key|2176080|text|servlet为您提供了比筛选器更细粒度的控制，因为您可以访问实际的目标“处理程序”-这意味着您执行的任何操作都可以根据请求的实际操作而变化(而HandlerInterceptor筛选器通常应用于所有请求-只能考虑每个请求的参数)。处理程序拦截器还提供了3种不同的方法，以便您可以在处理程序完成之后但在视图呈现之前(甚至可以完全绕过视图呈现)，或在呈现视图本身之后调用处理程序之前应用行为。此外，您还可以为不同的处理程序组设置不同的拦截器-拦截器在处理程序映射上配置，并且可能有多个处理程序映射。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2176081|因此，如果你需要做一些完全通用的事情(例如记录所有请求)，那么过滤器就足够了-但是如果行为依赖于目标处理程序，或者你想在请求处理和视图呈现之间做一些事情，那么HandlerInterceptor就提供了这种灵活性。|2176082|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A HandlerInterceptor gives you more fine-grained control than a filter because you have access to the actual target &quot;handler&quot; - this means that whatever action you perform can vary depending on what the request is actually doing (whereas the servlet filter is generically applied to all requests - only able to take into account the parameters of each request). The handler interceptor also provides 3 different methods, so that you can apply behavior prior to calling a handler after the handler has completed but prior to view rendering (where you may even bypass view rendering altogether), or after the view itself has been rendered. Also, you can set up different interceptors for different groups of handlers - the interceptors are configured on the handler mapping, and there may be multiple handler mappings.
Therefore, if you have a need to do something completely generic (e.g. log all requests), then a filter is sufficient - but if the behavior depends on the target handler or you want to do something between the request handling and view rendering, then the HandlerInterceptor provides that flexibility.

blocks|key|1689877|text|过滤器：顾名思义，过滤器是一个由servlet容器为每个传入的HTTP请求和每个HTTP响应执行的Java类。通过这种方式，可以在HTTP传入请求到达资源(如JSP页面、servlet或简单的静态页面)之前对其进行管理；以同样的方式，可以在资源执行之后管理HTTP出站响应。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1689878|Spring拦截器：Spring拦截器类似于Servlet过滤器，但它们工作在Spring上下文中，因此可以强大地管理HTTP和Response，但它们可以实现更复杂的行为，因为它们可以访问所有Spring上下文。|1689879|entityMap^0|0|3|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

Filter: - A filter as the name suggests is a Java class executed by the servlet container for each incoming HTTP request and for each HTTP response. This way is possible to manage HTTP incoming requests before they reach the resource, such as a JSP page, a servlet or a simple static page; in the same way, is possible to manage HTTP outbound response after resource execution.
Interceptor: - Spring Interceptors are similar to Servlet Filters but they act in Spring Context so are powerful to manage HTTP Request and Response but they can implement more sophisticated behaviour because can access all Spring context.

blocks|key|2176161|text|来自baeldung|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2176162|​|2176163|📷|atomic|2176164|2176165|筛选器在请求到达DispatcherServlet之前对其进行拦截，这使得它们非常适合粗粒度任务，例如：|2176166|Authentication
Logging+and+auditing
Image+and+data+compression
Any+functionality+we+want+to+be+decoupled+from+Spring+MVC|code-block|syntax|javascript|2176167|另一方面，HandlerIntercepors截获DispatcherServlet和我们的控制器之间的请求。这是在Spring+MVC框架中完成的，提供对处理程序和ModelAndView对象的访问。这减少了重复，并允许实现更细粒度的功能，例如：|2176168|Handling+cross-cutting+concerns+such+as+application+logging
Detailed+authorization+checks
Manipulating+the+Spring+context+or+model|2176169|entityMap|0|LINK|mutability|MUTABLE|url|https://www.baeldung.com/spring-mvc-handlerinterceptor-vs-filter#key-differences-and-use-cases|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/641076ee6e45027707e18a8bf19aff05.png|imageAlt^0|2|8|0|0|0|0|1|1|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|D|3|E|5|6|7|1C|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1D|8|@]|9|@$A|1E|B|1F|1|1G]]|C|$]]|$1|I|3|E|5|6|7|1H|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1I|8|@]|9|@]|C|$]]|$1|L|3|M|5|N|7|1J|8|@]|9|@]|C|$O|P]]|$1|Q|3|R|5|6|7|1K|8|@]|9|@]|C|$]]|$1|S|3|T|5|N|7|1L|8|@]|9|@]|C|$O|P]]|$1|U|3|-4|5|6|7|1M|8|@]|9|@]|C|$]]]|V|$W|$5|X|Y|Z|C|$10|11]]|12|$5|13|Y|14|C|$15|16|17|-4]]]]

From <a href="https://www.baeldung.com/spring-mvc-handlerinterceptor-vs-filter#key-differences-and-use-cases" rel="nofollow noreferrer">baeldung</a>:
<a href="https://i.stack.imgur.com/9iCub.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/9iCub.png" alt="filters_vs_interceptors" /></a>
Filters intercept requests before they reach the DispatcherServlet, making them ideal for coarse-grained tasks such as:
<pre><code>Authentication
Logging and auditing
Image and data compression
Any functionality we want to be decoupled from Spring MVC
</code></pre>
HandlerIntercepors, on the other hand, intercepts requests between the DispatcherServlet and our Controllers. This is done within the Spring MVC framework, providing access to the Handler and ModelAndView objects. This reduces duplication and allows for more fine-grained functionality such as:
<pre><code>Handling cross-cutting concerns such as application logging
Detailed authorization checks
Manipulating the Spring context or model
</code></pre>

I'm a little bit confused about <code>Filter</code> and <code>Interceptor</code> purposes. 

As I understood from docs, <code>Interceptor</code> is run between requests. On the other hand <code>Filter</code> is run before rendering view, but after Controller rendered response. 

So where is the difference between <code>postHandle()</code> in Interceptor and <code>doFilter()</code> in Filter? 

<a href="https://i.stack.imgur.com/1SMRk.png" rel="noreferrer"><img src="https://i.stack.imgur.com/1SMRk.png" alt="Spring MVC sheme"></a>
What is the best practise in which use cases it should be used?
In this picture where works <code>Filter</code>s and <code>Interceptor</code>s?

Difference between Interceptor and Filter in Spring MVC

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我对Filter和Interceptor的用途有点困惑。根据我在文档中的理解，Interceptor是在请求之间运行的。另一方面，Filter在渲染视图之前运行，但在控制器渲染响应之后运行。那么拦截器中的postHandle()和过滤器中的doFilter()的区别在哪里呢？​应该在哪些用例中使用它的最佳实践是什么？在...

问Spring MVC中拦截器和过滤器的区别
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Spring MVC中拦截器和过滤器的区别EN