Spring Security 两种资源放行策略，千万别用错了！

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！

两种方式最大的区别在于，第一种方式是不走 Spring Security 过滤器链，而第二种方式走 Spring Security 过滤器链，在过滤器链中，给请求放行。

在我们使用 Spring Security 的时候，有的资源可以使用第一种方式额外放行，不需要验证，例如前端页面的静态资源，就可以按照第一种方式配置放行。

有的资源放行，则必须使用第二种方式，例如登录接口。大家知道，登录接口也是必须要暴露出来的，不需要登录就能访问到的，但是我们却不能将登录接口用第一种方式暴露出来，登录请求必须要走 Spring Security 过滤器链，因为在这个过程中，还有其他事情要做。

接下来我以登录接口为例，来和小伙伴们分析一下走 Spring Security 过滤器链有什么不同。

2.登录请求分析

---

首先大家知道，当我们使用 Spring Security，用户登录成功之后，有两种方式获取用户登录信息：

1. SecurityContextHolder.getContext().getAuthentication()

2. 在 Controller 的方法中，加入 Authentication 参数

这两种办法，都可以获取到当前登录用户信息。具体的操作办法，大家可以看看松哥之前发布的教程：Spring Security 如何动态更新已登录用户信息？。

这两种方式获取到的数据都是来自 SecurityContextHolder，SecurityContextHolder 中的数据，本质上是保存在 ThreadLocal 中，ThreadLocal 的特点是存在它里边的数据，哪个线程存的，哪个线程才能访问到。

这样就带来一个问题，当