变量捕获不能传递threadlocal状态，仅复制局部变量快照；securitycontext、mdc等需显式快照与还原，否则导致上下文丢失或数据污染。
因为变量捕获本身不解决线程上下文传递问题，它只是把主线程的局部引用复制过去，而真正需要延续的是 ThreadLocal 中绑定的状态（如 SecurityContext、MDC、RequestAttributes），这些状态不会随 lambda 或匿名类的变量捕获自动迁移。
变量捕获 ≠ 上下文传递
写类似这样的代码很常见：
String userId = getCurrentUserId(); // 从 SecurityContextHolder 拿
CompletableFuture.runAsync(() -> {
// 用 userId 做事
log.info("User {} is processing async task", userId);
});
表面看“捕获了 userId”，但实际只保存了一个字符串快照。一旦业务逻辑需要动态获取当前用户权限、租户标识、请求头信息或 traceId，仅靠捕获的原始值就完全不够——它无法替代 SecurityContext 或 MDC 的实时能力。
ThreadLocal 状态根本不会被复制
Spring 安全上下文、日志追踪 ID、请求属性等都依赖 ThreadLocal 存储。而 ThreadLocal 是线程隔离的：
- 主线程里 set 的 SecurityContext，只存在于主线程的 ThreadLocalMap 中
- 异步线程启动时，它的 ThreadLocalMap 是空的，除非你主动 set
- 变量捕获不会触发任何 ThreadLocal 的 copy 或 inheritable 机制
更危险的是“伪成功”现象
有时候捕获看似有效，其实是巧合：
- 若主线程刚执行完 set，异步任务又很快执行，且未被其他任务复用该线程，可能暂时读到旧值
- 若线程池复用某个曾执行过其他请求的线程，而该线程的 ThreadLocal 还残留着上一次的 SecurityContext，就会导致用户信息错乱
- 这种非确定性行为在线上高并发场景中极易暴露为偶发性数据污染或越权访问
正确做法是显式快照与还原
不依赖变量捕获，而是对上下文做结构化快照和安全还原：
- 在拦截器或 AOP 切面中，用
MDC.getCopyOfContextMap()或SecurityContextHolder.getContext().clone()获取当前快照 - 将快照封装进 Runnable/Callable，例如用
TtlRunnable.wrap(runnable)或自定义包装器 - 在子线程 run() 开始时调用
MDC.setContextMap(...)和SecurityContextHolder.setContext(...) - 执行完毕后记得 clear，避免线程复用时污染后续任务
不复杂但容易忽略
