本次使用ThreadLocal存储uid的原因

这里使用ThreadLocal存储uid的原因：

本来使用request存储，因为token存在请求头中
//1、从请求头中获取令牌
String token = request.getHeader(jwtProperties.getAdminTokenName());
①HttpServletRequest作为形参②注入@Autowired HttpServletRequest
但是Controller层最好不要写很多业务逻辑只调用service服务。这个存储当前用户的逻辑应该给service层写入。
不能使用request，使用拦截器拿到token中的userID存储到一个区域，这个区域可以是本地存储，ThreadLocal也可以是一个存储数据库比如redis。
使用ThreadLocal的前提，这个请求到响应的执行全过程是同一个线程在操作(怎么看是不是一个线程在操作？看看流程有没有分叉)
ThreadLocal使用到的三个方法：set()向内部类ThreadLocalMap存储设置值，get()根据key获取值，ThreadLocal作为key。
remove移除当前线程的getMap，防止内存泄漏和线程污染问题。

Local Storage和ThreadLocal的概念。

Local Storage是浏览器中的一种机制，它被用来在浏览器中存储和读取数据。它以键值对的形式存储数据，并且在同一个域名下的不同页面之间共享数据。通过Local Storage，你可以在浏览器中永久存储数据，直到被显式删除。

ThreadLocal则是Java中的一个类，它提供了一种线程局部变量的解决方案。在多线程环境下，每个线程都有自己的ThreadLocal变量副本，线程之间互不影响。ThreadLocal的作用是为每个线程提供独立的变量副本，可以在整个线程执行期间被访问，修改和更新。

关于拦截器拿到了userId的情况，一般来说，这种身份信息是应该被安全地存储和使用的。对于userId这种与用户相关的敏感信息，建议将其存储在服务器端的Session中，而不是存在浏览器的Local Storage中。这样可以确保用户的身份信息得到保护，并且只在服务器端进行处理和验证。拦截器获取到的userId可以存储在ThreadLocal中，在整个请求处理流程中可以方便地获取和使用，同时也能保证每个线程使用的是自己的拦截器获取到的userId值。

总之，为了保护用户的身份信息安全，建议将userId等敏感信息存储在服务器端的Session中，而不是浏览器的Local Storage中。而在服务器端的处理过程中，可以使用ThreadLocal来存储和获取userId，保证每个线程独立地使用自己的userId值。

本文参考上一篇为什么使用ThreadLocal管理session和下一篇，如何使用ThreadLocal管理session