static方法不持有线程上下文，不应隐式依赖ThreadLocal，而应通过显式参数传递、TTL安全包装或ScopedValues作用域机制来保障跨线程上下文安全。
Java 中 static 方法本身不持有线程上下文，也不能直接参与上下文传递——它只是类级别的工具方法，没有 this、不绑定线程、也不自动感知当前线程的 ThreadLocal 状态。所以“static 方法如何处理跨线程上下文传递”这个问题，本质不是让 static 方法去“处理”，而是避免让它成为上下文传递的盲区或风险点。
下面从三个关键角度讲清楚怎么做：
static 方法不应隐式依赖 ThreadLocal
如果写一个 public static String getCurrentUserId() { return userThreadLocal.get(); }，看似方便，实则危险：
- 调用方可能没 set 过值，返回 null 或旧值
- 在异步线程、定时任务、线程池复用场景下极易读到错误上下文
- 单元测试难 mock，调用链路不可见，问题排查成本高
正确做法是：把上下文作为显式参数传入
立即学习“Java免费学习笔记（深入）”；
public static void processOrder(Long userId, Order order) {
// 业务逻辑使用 userId，不查 ThreadLocal
}
// 调用处由非 static 的入口方法负责获取并传入
processOrder(userThreadLocal.get(), order);static 方法可安全使用 TransmittableThreadLocal（TTL）值，但需包装到位
TTL 支持跨线程透传，但 static 方法仍不能“自动获得”父线程值——必须确保调用前已完成 capture，且执行环境已 replay。
常见安全用法：
- 所有提交到线程池的任务，必须用
TtlRunnable.get(() -> { ... })包装 - 若 static 方法在包装后的 Runnable 内被调用，它就能读到透传后的 TTL 值
- 不要在线程池外、未包装的子线程里调用该 static 方法，否则上下文为空
示例：
userTtl.set(1001L);
traceTtl.set("req-abc");
executor.submit(TtlRunnable.get(() -> {
// 此处调用 static 方法是安全的
OrderService.validateAndLog(userTtl.get(), traceTtl.get());
}));更推荐：用 Scoped Values 替代 ThreadLocal + static 组合（Java 19+）
Scoped Values 是为解决 ThreadLocal 隐式状态问题而设计的现代方案，天然适配 virtual thread，且作用域结束自动清理：
static final ScopedValue<Long> USER_ID = ScopedValue.newInstance();
static final ScopedValue<String> TRACE_ID = ScopedValue.newInstance();
// 在入口处绑定（如 WebFilter、AOP）
ScopedValue.where(USER_ID, 1001L)
.where(TRACE_ID, "req-abc")
.run(() -> service.handleRequest());
// static 方法可安全 get，但仅限于 run 内部
public static void logWithTrace() {
System.out.println("user=" + USER_ID.get() + ", trace=" + TRACE_ID.get());
}这种方式下，static 方法的调用安全性由作用域机制保障，无需手动 remove，也不会污染线程池。
不复杂但容易忽略：static 方法不是上下文的“接收端”，而是“消费端”；上下文传递的责任在调用链上游，不在 static 方法本身。
