seata中xid传递本质是上下文透传，通过拦截器在http（feign/resttemplate）、dubbo（filter+rpccontext）及异步场景中显式提取、注入并绑定到threadlocal，确保下游服务复用同一全局事务而非重复开启。
Seata 中 XID 的传递本质是“上下文透传”，核心目标是让下游服务能识别并加入同一个全局事务。它不依赖底层协议自动携带，而是靠框架在关键链路节点显式提取、注入和绑定。
HTTP 调用（如 Feign/RestTemplate）中 XID 传递
这是最常见场景，依赖请求头完成透传：
- 调用方从 RootContext.getXID() 获取当前线程绑定的 XID，通过拦截器（如
SeataRequestInterceptor或SeataRestTemplateInterceptor）将其写入请求头，标准 Header 名为 X-SEATA-XID - 被调用方在收到请求后，由 Spring MVC 拦截器（如
TransactionPropagationInterceptor）从请求头读取 XID，并调用 RootContext.bind(xid) 绑定到当前线程的 ThreadLocal 中 - 后续业务方法执行 SQL 时，
ConnectionProxy#commit()会检查RootContext.getXID() != null，从而决定是否注册分支事务
Dubbo RPC 调用中 XID 传递
Dubbo 不走 HTTP，需借助其 Filter 机制与 RpcContext 实现透传：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 消费端（Consumer）在发起调用前，通过自定义 Dubbo Filter（如
ApacheDubboTransactionPropagationFilter）将 XID 从RootContext取出，塞入RpcContext.getContext().setAttachment(KEY_XID, xid) - 提供端（Provider）在接收到调用后，同样通过 Filter 从
RpcContext.getContext().getAttachment(KEY_XID)取出 XID，并调用 RootContext.bind(xid) 绑定到当前线程 - 该 Filter 需通过 SPI 注册（
META-INF/dubbo/org.apache.dubbo.rpc.Filter），并在配置中启用：dubbo.provider.filter=seataTransactionFilter
异步调用与线程切换场景下的 XID 传递
ThreadLocal 天然不跨线程，XID 在线程池、CompletableFuture、@Async 等场景下会丢失：
- 手动透传：在提交任务前获取 XID，作为参数或上下文载体传入新线程，在新线程起始处调用 RootContext.bind(xid)
- 封装线程池：使用支持上下文继承的线程池（如 Alibaba TransmittableThreadLocal 封装的 TtlExecutors），确保子线程自动继承父线程的 XID
- 消息队列（如 RocketMQ/Kafka）：将 XID 作为消息头（headers）或扩展字段随业务消息发送，消费者端消费时取出并 bind 到当前线程
XID 传递是否会导致重复开启全局事务？
不会。XID 本身只是标识符，不触发事务开启逻辑：
-
@GlobalTransactional注解由GlobalTransactionalInterceptor拦截，仅当当前线程 未绑定 XID 时才向 TC 发起begin请求生成新 XID - 若下游服务方法也标注了
@GlobalTransactional，但当前线程已存在 XID（即已被上游透传绑定），则直接复用该 XID，注册为分支事务，而非新建全局事务 - 真正决定是否开启新全局事务的是 TM 的
begin调用，不是注解本身；XID 存在即表示“已处于某全局事务中”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
