那我反问你个问题 你每次需要时是不是都要去redis取吗？ 还是直接给你的好呢

这样就不用每次获取用户信息都从redis里取，从ThreadLocal取快又节省资源

threadlocal只见过当临时存储的。还可以当缓存用？

因为ThreadLocal是你这个程序用的，redis是一个中间件，其他程序也可以用。还有就是拓展性和设计。

上面说了用threadLocal的目的，但实际上不用threallocal也不是不行，但得看你们系统架构咋做的
如果是分布式的架构，只需要在最外层设计个网关，在网关里解析一下token，拿到一些必要的用户信息，之后把这些信息作为header透传给下游服务就可以了。
如果是单体应用，也有一招：可以用argumentReslover + 自定义注解 去自定义 controller层的对象解析，在解析器里面获取token，去redis里查询出用户信息，然后根据注解配置去注入对象；这样在api层就能直接通过自定义注解 + 对象去直接拿到用户信息了。
中心思想就是怎么实现在controller层之前统一拿到token解析用户信息，然后还能保证在controller层获取到用户信息，实现形式可以是五花八门的。

确实没啥必要，而且有个问题就是如果要更新用户信息。如果有多个线程保存了这个用户信息，那么怎么通知这些线程去更新用户信息？再加个订阅机制？反正把问题弄复杂了

上面的吧友回复的挺好的 我再补充一句 在软件设计中有一种思想: "immutable(不可变设计)" 这点在缓存中很重要 因为缓存会涉及解决缓存一致性问题。但如果使用缓存的场景 不是强一致性需求 或者说几乎不变 那么就可以使用 immutable(不可变设计) 解决问题
SourceData(在缓存中 ) -> Copy To -> ThreadObject(不允许修改缓存中SourceData)
如果 SourceData如果需要修改 需要一个专业的业务函数修改(权限业务 批量修改)
使用ThreadLocal 的一个意义是私有化Copy 使用SourceData和的ThreadObject 互不影响

减少io操作

没记错的话，redis存入了登陆态，用拦截器验证是否登陆。
在登陆时，拦截器从Redis拿下来存入的threadlocal，相当于存入一个map，减少了之后需要登录信息时，对redis 的多次io

你可以理解为一个请求就开启一个线程，从redis中取出来数据经过操作之后存到当前线程本地变量，在这个线程结束之前一直可以从线程本地变量中取出数据使用，

看来没遇见过特殊场景，假如一个接口开头和末尾都要用到用户信息，如果开头能取到，但是末尾突然取不到或取到不正确的值导致业务异常（无论是用户正常的登出或修改用户信息改变了redis数据，redis出现故障），如果在接口一开始从redis里取出放到threadlocal里，接口里后续业务处理能够按照稳定的信息去处理