核心是“一次绑定、全程可见、线程隔离、用完即清”，即在最外层拦截器prehandle中解析token并设入static final threadlocal，中间拦截器只get不set，finally或aftercompletion中remove防泄漏，推荐配合requestcontextholder更稳健。
在多层拦截器中用 ThreadLocal 传递鉴权状态，核心是“一次绑定、全程可见、线程隔离、用完即清”。关键不在于存，而在于**谁来存、何时存、谁来清、如何防泄漏**。
拦截器链中统一注入鉴权上下文
通常在最外层（如 Spring 的 HandlerInterceptor.preHandle）完成解析与绑定。此时已通过 Token、Cookie 或 Header 获取用户身份，应构造不可变的鉴权对象（如 AuthContext），并设入 ThreadLocal：
- 避免在多个拦截器里重复解析或判空，只做一次可信初始化
- 推荐使用
static final ThreadLocal<authcontext></authcontext>+withInitial，避免每次 get() 返回 null - 示例：
private static final ThreadLocal<authcontext> CONTEXT = ThreadLocal.withInitial(() -> AuthContext.ANONYMOUS);</authcontext>
中间拦截器直接读取，不修改也不重设
后续拦截器（如权限校验、日志埋点、租户路由）只需调用 CONTEXT.get() 获取当前请求的认证信息：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 禁止调用
set()—— 防止污染上游上下文或覆盖原始鉴权结果 - 若需扩展字段（如动态角色列表），应在初始
AuthContext中预留可扩展结构（如Map<string object> attributes</string>），而非另起一个ThreadLocal - 对匿名/非法请求，仍保持
AuthContext.ANONYMOUS占位，避免空指针，也便于统一审计
务必在 finally 块中 remove() 清理
Spring 拦截器的 afterCompletion 是清理的黄金位置。但要注意：即使发生异常或提前返回，也必须保证 remove() 执行：
- 不要只在
afterCompletion里 remove —— 若拦截器链未执行到该阶段（如被前序拦截器 return false），就会泄漏 - 最佳实践：在
preHandle绑定后，立即注册一个 try-finally 结构（可用ThreadLocal包装工具类封装） - 尤其警惕异步场景：若拦截器内启了新线程（如
CompletableFuture.supplyAsync），ThreadLocal不会自动传递，需显式拷贝（如用InheritableThreadLocal或手动透传）
配合 Spring WebMvc 的 RequestContextHolder 更稳健
纯 ThreadLocal 在某些容器（如 Tomcat 使用线程池复用）下易出问题。Spring 提供了更上层的抽象：
- 启用
RequestContextFilter（WebMvc 场景下默认开启），它会在每次请求开始时绑定ServletRequestAttributes到RequestContextHolder - 可在其中安全存放鉴权对象：
RequestContextHolder.currentRequestAttributes().setAttribute("auth", ctx, RequestAttributes.SCOPE_REQUEST) - 优势：生命周期由 Spring 管理，自动解绑；支持 AOP、Async、Test 等上下文；且与
@RequestScopeBean 天然协同
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
