正常要请求/oauth2/authorization/{regId}跳转到authorization-uri进行认证的，但是搭建好之后，请求这个地址竟然直接报404了，说明oauth2的相关filter并没有生效，直接打到了dispatchServlet。

那到底是哪里的问题呢？debug一天发现在FilterChaninProxy中发现了问题所在。

需要知道的是oauth2对于这个uri处理的filter是OAuth2AuthorizationRequestRedirectFilter进行重定向的。

出问题的时候 FilterChaninProxy中的List<SecurityFilterChain> filterChains 有三组。

第一组：是处理普罗米修斯相关的内容，不用考虑。

 第二组：拦截路径是/**,filter有12个。但是里面并没有需要的filter。 

第三组：拦截地址也是任意请求，里面我们需要的filter。其实这里可以看出这个chain里面的filter和oauth2的流程密切相关。

那既然chain里面有需要的filter，为什么没有拦截到呢。一通查找，在官网上看到了相关描述如下：

 大概意思就是说如果有多组SecurityFilterChain,只要有一组chain能匹配到，后面的chain中的filter就不会执行了。这不就是现在碰到的问题吗？第二组的chain拦截路径/**其实已经执行过了，第三组中的filter是不会执行的。在代码中的体现就是下面的代码：

 三组securityFilterChain只要有一组匹配的上就返回。

好了，发现问题了，那这个问题怎么来的呢？这个顺序哪里决定的呢？又是一通debug

找到了这三个chain和WebSecurityConfigurer 配置有关。

 启动过程中会找WebSecurityConfigurer 的相关bean。这里找到了三个：

前两个是项目上自定义的webSecurity相关的。第三个是@EnableResourceServer相关的。

但是这个顺序还不是最后的顺序。 

  得到三个配置之后会进行排序。排序之后的顺序就变成下面的样子了：

 还有一点需要注意：排序完不能有顺序相同的configure，不然会抛异常。

 上面三个配置会被WebSecurity webSecurity 用来构建SecurityFilterChain，因此只要解决这里configure的构建顺序让@EnableResourceServer相关的放到webSecurityConfigure之后，就可以调整securityFilterChain的顺序了。

对于@EnableResourceServer 配置默认order是3，在源码上可以看到。

 因为另外一个SecurityConfigure顺序是2，所以对于项目上继承WebSecurityConfigurerAdapter的配置设置顺序为1。

 至此，问题解决了。