对象内聚属性不参与TraceId注入，真正起作用的是线程上下文（如MDC）、请求上下文（如HttpServletRequest）和跨切面执行流控制（如AOP），TraceId依赖执行上下文而非对象属性。
对象内聚属性本身不直接参与 TraceId 注入，它也不是一个可被“利用”的注入通道。真正起作用的是线程上下文（如 MDC）、请求上下文（如 HttpServletRequest 或 ServerWebExchange）以及跨切面的执行流控制（如 AOP）。所谓“不破坏侵入性”，核心是避免在业务代码中显式调用 MDC.put("traceId", ...) 或手动透传 ID —— 而不是靠对象字段“自带”传播能力。
TraceId 本质依赖执行上下文，而非对象属性
Java 中 TraceId 的传递必须依托某种“载体上下文”：
-
线程级载体：MDC 是 SLF4J 提供的
ThreadLocal<Map>，天然绑定当前线程，日志打印时自动读取； -
请求级载体：HTTP 请求头（如
X-Trace-ID）、gRPC 的Metadata、消息中间件的 headers； -
调用链载体：OpenTelemetry 的
Context、Sleuth 的Tracer.currentSpan()、SkyWalking 的ContextManager。
业务对象（比如 UserOrder、PaymentRequest）即使有高内聚字段（如 userId、orderId），它们也不携带或传播 TraceId —— 这类字段属于业务语义，不是可观测性基础设施。
真正无侵入的注入路径：从入口到组件自动透传
要让底层组件（如 DAO、FeignClient、XXL-Job 任务、异步线程池）拿到 TraceId，关键是把 ID 从入口“带进去”，而不是塞进业务对象里：
- Web 层：用 Filter / WebFilter 拦截请求，生成或提取 TraceId → 写入 MDC + 当前线程的 OpenTelemetry Context；
-
RPC/HTTP 客户端：通过拦截器（如 Feign 的
RequestInterceptor、RestTemplate 的ClientHttpRequestInterceptor）自动将 MDC 中的 traceId 注入请求头； -
定时任务：用 Spring AOP 拦截
@XxlJob方法，在执行前从父线程（如调度线程）继承或生成新 traceId，并写入 MDC； -
异步场景：包装线程池（如
ThreadPoolTaskExecutor），在beforeExecute中将主线程 MDC 拷贝到子线程； -
数据库操作：无需改 DAO，只要日志框架（Logback）配置了
%X{traceId}，且 MyBatis/ JDBC 日志由 SLF4J 输出，就会自动带上。
为什么不能靠“对象内聚属性”注入？
常见误解是：给业务对象加个 traceId 字段，然后层层 set/get。这会带来严重问题：
- 所有 DTO、VO、Entity 都需修改，违反开闭原则；
- 底层组件（如 JPA Repository）并不接收这些对象作为上下文，无法感知该字段；
- 异步调用、线程切换后对象引用失效，TraceId 断裂；
- 日志框架不会自动读取对象字段，仍需手动
log.info("traceId={}, {}", obj.getTraceId(), msg)，丧失 MDC 的自动化优势。
推荐做法：用标准上下文 + 适配层收口
保持业务对象纯粹，把 TraceId 管理下沉到框架层：
- 统一用
MDC.put("traceId", id)入口处写入，日志模板写%X{traceId}； - 对外调用统一走封装好的 HTTP 客户端（内置 header 注入逻辑）；
- 对内调用（如 Service → Mapper）不传 ID，靠线程上下文自然延续；
- 若必须跨线程（如
@Async），用@Async自定义 TaskDecorator 包装 MDC； - 非 Spring 场景（如纯 Java SE 工具类），用
Context.copyFromCurrent()（OpenTelemetry）或自定义ThreadLocal工具类。
不复杂但容易忽略。
