data-*属性不可靠，因仅限浏览器dom层、无法跨线程/服务/协议透传；真正透传需运行时上下文管理——前端用拦截器注入x-trace-id头，后端用filter提取并绑定mdc，feign与异步场景需配合ttl等机制保障一致性。
直接用 HTML 自定义属性（data-*）透传 traceId 是不可靠的，也不符合链路追踪的设计原则。它无法解决跨线程、跨服务、跨协议的上下文传递问题，更不能保障日志、RPC、异步任务间的 TraceID 一致性。真正安全透传 traceId，关键在运行时上下文管理，而非 DOM 节点属性。
为什么 data-* 不适合承载 traceId
DOM 自定义属性仅存在于浏览器渲染层，生命周期绑定页面节点，不具备以下能力：
- 无法跨 iframe 或微前端子应用自动同步
- 服务端无法读取前端 DOM 属性（除非主动序列化后发请求）
- HTTP 请求头、消息队列、定时任务、线程池等后端场景完全不可见
- 前端 JS 修改
data-trace-id后，若未显式写入请求头或 MDC，下游服务仍收不到
真正起作用的是运行时上下文透传机制
traceId 的安全透传依赖统一的上下文载体和标准化注入点，核心是让 traceId 在每次调用出口“自动带上”，在入口“自动绑定”：
-
前端发起 HTTP 请求时：通过 Axios 拦截器或 Fetch middleware 自动注入
X-Trace-Id头，值来自全局 trace 上下文（如 OpenTelemetry 的 currentSpan） -
后端接收请求时：用 Filter/Interceptor 提取
X-Trace-Id，存入 MDC 或 ThreadLocal，并确保后续日志、Feign 调用、@Async 任务均可继承 -
Feign 远程调用时：配置
RequestInterceptor从 MDC 取值并写入请求头；异步场景需搭配TransmittableThreadLocal或TtlRunnable -
消息中间件（如 Kafka）：生产者将 traceId 写入消息 header（如
trace-id），消费者启动时从 header 提取并绑定到当前线程
DOM 层可辅助但不可替代：只做轻量级展示与调试
如果确需在前端界面体现 traceId（例如用于问题上报、日志关联、灰度标识），可安全使用 data-trace-id，但必须满足两个前提：
- 该值来自可信上下文（如从响应 header 读取、或由 OpenTelemetry SDK 生成），而非用户输入或 DOM 操作随意设置
- 仅用于只读展示或前端埋点，不参与任何服务间调用逻辑
示例（React 中安全注入）：
useEffect(() => {
const traceId = getCurrentTraceId(); // 来自 OTel SDK
document.body.setAttribute('data-trace-id', traceId);
}, []);验证是否真正透传成功的关键动作
不要只检查 DOM 是否有 data-trace-id，而要逐跳确认：
- 浏览器 Network 面板中，所有出站请求是否含
X-Trace-Id头且值一致 - 目标服务日志开头是否打印该 traceId（如
[X-Trace-Id=abc123]） - 该服务再调用下游 Feign 接口时，发出的请求头是否延续同一 traceId
- 下游服务 Controller 日志中能否看到相同 traceId，且能查到完整调用链
