结论：不能只靠TransmittableThreadLocal自动解决SecurityContext丢失问题，必须配合SecurityContextHolder策略切换与TTL显式包装。因Spring Security默认MODE_THREADLOCAL依赖ThreadLocal，线程池复用线程时不继承上下文，且残留Context引发安全风险；须设MODE_INHERITABLETHREADLOCAL（需启用系统属性）、用TtlExecutors包装线程池或TtlRunnable包装任务，并注意浅拷贝、CompletableFuture兼容性等问题。
直接说结论：不能只靠 TransmittableThreadLocal 自动解决 SecurityContext 丢失问题，必须配合 Spring Security 的 SecurityContextHolder 策略切换 + TTL 显式包装，否则线程池中拿到的仍是空上下文或旧残留。
为什么 SecurityContext 默认在线程池里必然丢失
Spring Security 默认使用 MODE_THREADLOCAL，底层依赖标准 ThreadLocal。而线程池复用线程时，既不会触发 InheritableThreadLocal 的继承（因为线程早已存在），也不会自动捕获主线程当前的 SecurityContext 实例。更危险的是：若前一个任务没清理 SecurityContextHolder，后续任务可能读到其他用户的认证信息——这是典型的安全隐患。
必须改掉 SecurityContextHolder 的存储策略
仅把 SecurityContext 存进 TransmittableThreadLocal 不够，Spring Security 不会主动从你自定义的 TTL 容器里读取。得让它“愿意配合”：
- 在应用启动类或配置类中强制设置：
SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL) - 但注意：这仍不足以支持线程池，只是为后续 TTL 接入打基础；
MODE_INHERITABLETHREADLOCAL仅对new Thread()有效 - 真正起效的是配合 TTL 的「快照+还原」机制，而非单纯换策略
TTL 包装必须作用于任务提交入口，不是 Context 设置点
常见错误是只在 Controller 里调用 SecurityContextHolder.getContext().setAuthentication(...)，然后期望线程池自动感知。实际必须在提交异步任务那一刻完成上下文捕获：
- 用
TtlRunnable.get(() -> { /* 业务逻辑，里面可直接调 SecurityContextHolder.getContext() */ }) - 或更推荐：用
TtlExecutors.getTtlExecutorService(executor)包装整个线程池，一劳永逸 - 如果用
@Async，需自定义AsyncConfigurer，返回的Executor必须是 TTL 包装过的，原生ThreadPoolTaskExecutor不行 - 切记：不要在子线程里手动调
SecurityContextHolder.setContext(...)，TTL 已在执行前自动还原，重复设置反而可能覆盖快照
容易被忽略的清理与兼容性陷阱
即便用了 TTL，仍有两个关键点常被跳过：
-
SecurityContext是对象引用，TTL 默认传递的是浅拷贝。若 context 内部含可变状态（如某些自定义Authentication实现），需确保其clone()或getAuthorities()等方法线程安全 - Spring Security 5.7+ 默认禁用
MODE_INHERITABLETHREADLOCAL，启动时会报 warning；必须显式允许：System.setProperty("spring.security.allowInheritableThreadLocalAccess", "true") - 若项目混用
CompletableFuture，需额外用TtlForkJoinPool或手动包装supplyAsync，默认的ForkJoinPool.commonPool()不受 TTL 控制
