必须用transmittablethreadlocal显式承载securitycontext并配合ttl增强的线程池，才能跨线程传递spring security上下文；否则因线程复用与threadlocal隔离导致信息必然丢失。

跨线程传递业务上下文（比如 Spring Security 的 SecurityContext）时信息丢失，不是代码漏写了 set()，而是机制不匹配导致的必然结果。核心问题在于：线程池复用线程 + 默认 ThreadLocal 隔离 + Spring Security 不主动读取自定义容器，三者叠加造成上下文“看不见、传不过、清不掉”。解决它得从机制层入手，而不是靠 try-catch 或手动搬运。

必须切换 SecurityContextHolder 存储策略

Spring Security 默认用 MODE_THREADLOCAL，只对当前线程有效；换成 MODE_INHERITABLETHREADLOCAL 也只是为后续透传铺路，并不能直接解决线程池场景：

• 在应用启动类或配置类中强制设置：SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL)
• 该设置仅让新创建的线程能继承父线程上下文，对线程池中已存在的工作线程无效
• 真正起效依赖的是 TTL 的捕获-回放机制，不是这个策略本身

用 TransmittableThreadLocal 显式承载 SecurityContext

不能指望 Spring 自动把 SecurityContext 塞进你自定义的容器里，得自己把它“拎出来”再“放进去”：

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

• 声明一个静态 final 的 TTL 容器：static final TransmittableThreadLocal<securitycontext> securityContextTtl = new TransmittableThreadLocal();</securitycontext>
• 在过滤器或拦截器中捕获并设置：securityContextTtl.set(SecurityContextHolder.getContext());
• 注意值类型应为不可变对象，SecurityContext 本身可变，建议封装成只读副本或深拷贝

任务提交前必须做 TTL 包装

上下文捕获发生在主线程，还原发生在子线程执行前——这个时机不能错：

• 显式提交任务时，用 TtlRunnable.get(() -> { /* 业务逻辑 */ }) 包装
• 使用 @Async 时，不能直接用原生 ThreadPoolTaskExecutor，要通过 TtlExecutors.getTtlExecutorService() 包装，或配合 TaskDecorator 统一注入
• CompletableFuture 使用 supplyAsync(..., executor) 时，executor 必须是 TTL 增强过的

每次执行后务必清理，防止线程污染

线程池线程被复用，若不清理，下一个任务可能拿到上一个用户的 SecurityContext，这是严重安全风险：

• 在 Runnable/Callable 执行末尾调用 securityContextTtl.remove()
• 更稳妥的做法是在 try-finally 中清理：try { ... } finally { securityContextTtl.remove(); }
• 避免在子线程内调用 SecurityContextHolder.setContext()，TTL 已自动还原，重复设置反而破坏一致性

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南