静态变量不可用于链路追踪，因其被所有线程共享，导致多请求间 traceid 相互覆盖、异步任务失效、无法满足分布式追踪标准；应使用 threadlocal、mdc 或 opentelemetry 等线程隔离方案。
直接用类的静态变量实现链路追踪因子，不可行，也不安全。
为什么静态变量不能用于链路追踪
静态变量属于类级别，在 JVM 中被所有线程共享。而一个微服务实例通常要同时处理成百上千个并发请求，每个请求都需独立的 TraceId 和 Span 上下文。若用 static String traceId = "xxx" 这类方式：
- 多线程会相互覆盖，A 请求刚设好 traceId，B 请求立刻写入新值，A 的日志全变成 B 的 ID
- 无法区分父子调用关系，SpanId、ParentSpanId 等结构化信息无法在线程间隔离
- 异步任务（如 CompletableFuture、@Async）会脱离原始线程，静态变量完全失效
- 不满足 OpenTracing / W3C Trace Context 等标准，无法与 Zipkin、Jaeger、SkyWalking 等系统对接
真正轻量且可行的替代方案
不是靠“共享”，而是靠“线程局部隔离 + 自动透传”：
-
MDC（Mapped Diagnostic Context）：SLF4J 提供的线程绑定机制。Spring Boot 中可配合 Filter + MDC.put("traceId", id) 实现请求级上下文注入，logback 日志模板用
%X{traceId}即可输出；跨线程需手动 copy（如用 ThreadPoolTaskExecutor 装饰器） -
ThreadLocal + 工具类封装：定义
TraceContext类，含 traceId、spanId、parentSpanId 字段；用static final ThreadLocal<tracecontext></tracecontext>存储，入口生成、出口清理，比裸 static 安全得多 -
Nginx $request_id + Header 透传：在网关层生成 UUID 并设为
X-Request-ID，后端统一读取并注入 MDC/ThreadLocal；零代码改动即可获得基础链路标识 -
OpenTelemetry SDK 自动埋点：引入
opentelemetry-javaagent.jar启动参数，无需改一行业务代码，自动支持 HTTP、gRPC、DB、Redis 等组件的 Span 创建与传播
如果坚持“静态变量风格”的极简实践
仅限单线程调试或 Demo 场景，生产环境请勿使用：
- 定义
public class TraceHolder { public static final ThreadLocal<string> TRACE_ID = ThreadLocal.withInitial(() -> IdUtil.simpleUUID()); }</string> - 在 WebFilter 中
TraceHolder.TRACE_ID.set(extractFromHeader(request))，响应前TraceHolder.TRACE_ID.remove() - 日志中通过
TraceHolder.TRACE_ID.get()获取，但必须确保每次请求都走完整 set/remove 流程
本质不是“共享”，而是“每个线程独占一份，由框架保证生命周期”。所谓轻量，是接入成本低、资源开销小、不依赖外部中间件——不是靠牺牲正确性换来的“省事”。
