它扩展了GenericFilterBean以获得此功能。
我想我会换一种说法。根据GenericFilterBean的JavaDoc：

/**
 * This generic filter base class has no dependency on the Spring  
 * org.springframework.context.ApplicationContext concept. Filters usually 
 * don't load their own context but rather access service beans from the 
 * Spring root application context, accessible via the filter's 
 * ServletContext

**/

另请注意GenericFilterBean的JavaDoc：

/**
 * This filter leaves actual filtering to subclasses, which have to implement 
 * the Filter.doFilter method.

**/

或者，IOW，GenericFilterBean获取init-param，将它们注册为Springbean属性，并将这些属性应用于过滤器。init-param的容量有限，并且doFilter仍然需要以任一方式实现。
这就是DelegatingFilterProxy的用武之地。它从应用程序上下文中查找Filter类型的bean，并在它自己的doFilter方法中代理它。该代理允许应用程序指定Filter类型的bean，该bean依赖于Spring的生命周期，而不是servlet容器的生命周期。
您可以在DelegatingFilterProxy的JavaDoc中看到详细信息：

/**
  * This approach is particularly useful for Filter implementation with 
  * complex setup needs, allowing to apply the full Spring bean definition 
  * machinery to Filter instances.
  */

• 注意 *：Sping Boot 应用程序也可以发布FilterRegistrationBean类型的Bean，以指定基础过滤器、其顺序和分派器类型。

这两个类似乎都可以直接连接到web.xml
是什么让您产生这种印象呢？鉴于GenericFilterBean是abstract，我不清楚如何在web.xml文件中引用它。Servlet容器将无法构造它。
Spring Security是否使用DelegatingFilterProxy来调用FilterChainProxy
是的，我知道
Spring Security选择使用Filter API，而不是自己发明API。正因为如此，它非常符合DelegatingFilterProxy的用途。（例如，您可以想象，如果人们只通过web.xmlinit-param来配置Spring Security，会受到多大的限制。）
假设，如果Spring Security决定创建自己的类似过滤器的API，它将拥有自己的GenericFilterBean实现，该实现以不同的方式实现doFilter。
尽管后者已经扩展了GenericFilterBean
我认为您的问题的这一部分是在问“既然FilterChainProxy实现了GenericFilterBean，难道不能将其指定为servlet容器的过滤器吗？”答案是“不能”。
DelegatingFilterProxy的另一个好处是它允许延迟查找Filter bean示例。这一点很重要，因为容器需要在启动之前注册Filter示例。但是，Spring通常使用ContextLoaderListener来加载Spring Bean，而这要等到需要注册Filter示例之后才能完成。
那么，它为什么要扩展GenericFilterBean呢？大多数Spring过滤器都扩展了GenericFilterBean，因为它允许应用程序更灵活地像构建块一样使用它们。就像它的JavaDoc所说的那样：

/**
  * A handy superclass for any type of filter.
  */