ThreadLocal在切面中取不到值，本质是线程切换导致上下文未传递：Controller设值后若经@Async、CompletableFuture、Dubbo Filter等触发线程切换，切面运行在新线程，而ThreadLocal不跨线程，故get()返回null。
ThreadLocal 在切面（Aspect）中“丢失”值，本质不是变量失效，而是上下文没传过去——切面执行时所在线程，和你设值的线程不是同一个。
为什么切面里 get() 返回 null？
典型场景：在 Controller 层用 ThreadLocal.set(userId) 存用户 ID，接着进 @Service 方法，再触发 @Around 切面，结果切面里 get() 拿到的是 null。原因很直接：
- Controller 和 Service 默认跑在同一个线程（比如 Tomcat 的 worker 线程），设值没问题；
- 但一旦中间有异步操作（如
CompletableFuture、@Async、线程池 submit）、或用了某些代理增强（如 Dubbo Filter、Netty EventLoop），就会切换线程； - 切面方法实际运行在线程切换后的线程上，而 ThreadLocal 不跨线程，自然查不到原值。
常见“隐形线程切换”路径
这些地方看似同步，实则悄悄启了新线程，导致切面脱离原始上下文：
- @Async 方法：Spring 默认用 SimpleAsyncTaskExecutor，每次新建线程，InheritableThreadLocal 都不生效；
-
CompletableFuture 异步链：
supplyAsync()或thenApplyAsync()若没显式传带透传能力的 Executor，就用 ForkJoinPool.commonPool()，值无法继承； - Dubbo Filter / Interceptor：服务端收到请求后，可能在业务线程池中执行 Filter，此时主线程的 ThreadLocal 已不可见；
- ParallelStream：底层走 ForkJoinPool，首次初始化会复制一次主线程值，后续复用线程不再更新，造成“旧值残留”；
- 消息监听器（@KafkaListener / @RabbitListener）：由独立消费者线程拉取消息，与 Web 请求线程完全隔离。
切面中如何可靠拿到上下文？
不能依赖“自动继承”，得主动传递或重建。推荐三类做法：
- 提前快照 + 显式传参：在进入异步/代理前，把关键字段（如 userId、traceId）取出来，作为参数传入后续逻辑，切面从方法参数或对象属性读取；
-
用 TransmittableThreadLocal（TTL）+ 正确包装：替换所有
ThreadLocal为TransmittableThreadLocal，且确保线程池、@Async、CompletableFuture 全部使用TtlExecutors包装过的实例； - 切面内重绑定（慎用）：若调用链起点明确（如 ServletRequest），可在切面里从 Request Attributes、Header 或 MDC 中重新提取并 set 到当前线程的 ThreadLocal，但需注意清理时机，避免污染。
特别注意线程池复用带来的污染
即使用了 TTL，如果线程池未正确包装，或忘记在 finally 块中 remove()，会出现“上次请求的 userId 冒充本次请求”的问题。尤其在高并发下，一个线程处理多个请求，旧值残留会导致权限错乱、日志串号、租户数据越界等严重后果。
建议所有 ThreadLocal 使用都遵循“set → 业务逻辑 → remove”闭环，最好封装成工具类或 try-with-resources 形式。
