Java中ThreadLocal配合Spring Security传递用户信息的核心是利用SecurityContextHolder的MODE_THREADLOCAL策略自动管理线程隔离的SecurityContext，需在自定义JWT过滤器中解析并注入认证信息，并在请求结束时清理以避免线程复用污染。
Java 中 ThreadLocal 配合 Spring Security 传递用户信息，核心是利用 SecurityContextHolder 的线程绑定机制，再结合自定义拦截器或过滤器完成 JWT 解析与上下文注入。它不是“手动用 ThreadLocal 存用户”，而是 Spring Security 默认就基于 ThreadLocal 实现的——你只需正确配置、解析并清理。
Spring Security 默认就是靠 ThreadLocal 工作的
SecurityContextHolder 默认使用 MODE_THREADLOCAL 策略，内部通过 ThreadLocal 存储当前认证状态。每次请求进入时，只要成功设置过 SecurityContext，后续任意 Service 或 Controller 层调用 SecurityContextHolder.getContext().getAuthentication() 就能拿到用户信息，无需参数传递。
这背后就是每个请求线程独享一个 SecurityContext 副本，天然隔离多用户并发场景。
关键：在过滤器中解析 JWT 并写入 SecurityContext
Spring Security 原生的登录流程（如表单提交）会自动填充上下文，但 JWT 场景需自定义过滤器。常见做法：
- 继承
OncePerRequestFilter，重写doFilterInternal - 从请求头（如
Authorization: Bearer xxx）提取 JWT - 校验签名、过期时间，解析出用户 ID、角色等信息
- 构造
UsernamePasswordAuthenticationToken（含Principal和GrantedAuthority列表） - 调用
SecurityContextHolder.getContext().setAuthentication(token)
之后整个请求链路（包括 MVC Handler、AOP、事务管理器）都能通过 SecurityContextHolder 获取当前用户。
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。
必须注意线程复用带来的污染风险
Tomcat 或 Netty 的线程池会复用线程处理多个请求。若不清理，上一个请求留下的 SecurityContext 可能被下一个请求误读——导致用户串号或权限错乱。
解决方式有二：
-
推荐：在过滤器链末尾或
afterCompletion回调中调用SecurityContextHolder.resetContext() - 或统一配置为可继承模式 + TaskDecorator（适用于异步线程）：
SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL)，并在ThreadPoolTaskExecutor中用TaskDecorator拦截任务，执行前复制、执行后清除上下文
不建议重复造轮子：别另建 UserContext 类
有人习惯额外定义 UserContext 类封装 ThreadLocal，再在拦截器里 set/get。这种做法冗余且易出错：
- 绕过了 Spring Security 的权限决策器（
AccessDecisionManager）、注解（@PreAuthorize）等能力 - 需要自己维护生命周期，稍有遗漏就会内存泄漏或数据残留
- 和 SecurityContextHolder 不同步，可能出现“认证通过但取不到用户”或“取到旧用户”问题
正确姿势是信任并用好 SecurityContextHolder —— 它已为你封装好线程安全、清理逻辑和扩展点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
