本质是ThreadLocal无法跨线程自动传递，因线程池复用导致上下文丢失；解决需用TransmittableThreadLocal替代，并配合TtlRunnable包装任务或TaskDecorator统一注入，同时主动清理避免污染。
线程池中用户信息丢失，本质是 ThreadLocal 无法跨线程自动传递。主线程（如 Tomcat 线程）设置的用户 ID、安全上下文等，到了线程池的工作线程里就变成 null —— 不是因为代码写错了，而是 Java 线程模型本身的限制。解决它不靠“手动 set/clear”，而要靠机制化、可复用、无侵入的设计。
用 TransmittableThreadLocal（TTL）替代普通 ThreadLocal
普通 ThreadLocal 和 InheritableThreadLocal 都不适用于线程池场景：前者完全隔离，后者只在 new Thread() 时继承，对线程池无效。TTL 是阿里开源的增强版，专为异步透传设计。
- 把原来用 ThreadLocal<User> 的地方，换成 TransmittableThreadLocal<User>
- 初始化方式不变：static final TransmittableThreadLocal<User> currentUser = new TransmittableThreadLocal<>();
- 在过滤器或拦截器中设置：currentUser.set(user);
- 后续所有被 TtlRunnable 或 TtlCallable 包装的任务，都能自动读到该值
包装任务：TtlRunnable 是最轻量可靠的方案
当你显式调用 executor.submit(runnable) 时，只需一层包装，上下文即可透传。
- 不用改业务逻辑，只要把原始 Runnable 包一层：executor.submit(TtlRunnable.get(() -> { /* 你的异步逻辑 */ }))
- 如果是 Callable，用 TtlCallable.get(() -> { return result; })
- 注意：必须确保提交前，主线程已设置好 TTL 变量；否则子线程拿到的是空值
- 适用于自定义线程池、CompletableFuture.supplyAsync(…, executor) 等所有显式传入 Runnable/Callable 的场景
集成 Spring @Async：用 TaskDecorator 统一注入
如果你大量使用 @Async，逐个包装不现实。Spring 提供了 TaskDecorator 接口，可在任务执行前后统一处理上下文。
- 定义装饰器：public class ContextCopyingDecorator implements TaskDecorator { public Runnable decorate(Runnable runnable) { return TtlRunnable.get(runnable); } }
- 配置线程池 Bean 时注入：taskExecutor.setTaskDecorator(new ContextCopyingDecorator());
- 此后所有 @Async 方法、@Scheduled 方法、甚至 ThreadPoolTaskScheduler 的任务，都会自动携带主线程上下文
- 比重写 AsyncConfigurer 更干净，也避免了 AOP 代理失效等边界问题
安全清理：避免线程复用导致的上下文污染
线程池线程会被反复使用。若某次任务设置了用户信息但未清理，下次执行可能误读旧值 —— 这比丢失更危险。
- TTL 默认不会自动 remove，需主动调用 TransmittableThreadLocal.super.remove() 或封装工具方法
- 推荐在请求结束阶段（如 Filter 的 finally 块、WebMvcConfigurer 的 afterCompletion）统一清理：currentUser.remove();
- 若用 Spring Security，还需同步清理 SecurityContextHolder.resetContext()，防止认证信息残留
- CompletableFuture 使用后建议显式调用 TtlUnwrap.unwrap()（如有嵌套异步），确保透传链完整
