SpringBoot切换RestClient后跨服务TraceId不一致问题求助

不少开发者在从RestTemplate迁移到RestClient时都遇到过TraceId跨服务传递失效的问题，以下是几个常见的排查方向和解决方案：

1. 检查RestClient的Bean配置是否正确注入Trace拦截器 #

Spring Cloud Sleuth或Micrometer Tracing的Trace传递依赖于请求拦截器注入traceparent等头信息。如果是手动创建RestClient实例，必须确保拦截器被正确添加：

@Bean
public RestClient restClient(TraceRestClientInterceptor traceInterceptor) {
    return RestClient.builder()
            .requestInterceptor(traceInterceptor)
            .build();
}

如果使用RestClient.Builder自动配置，要确认没有覆盖默认的拦截器配置逻辑。

2. 验证Tracing依赖版本兼容性 #

确保Spring Boot、Spring Cloud（或Micrometer Tracing）版本兼容，部分旧版本对RestClient的Tracing支持存在缺陷：

• Spring Boot 3.x 需搭配 Micrometer Tracing 1.1.x+
• Spring Cloud 2022.0.x（Kilburn）及以上版本

3. 检查请求头是否被手动覆盖 #

如果在RestClient请求中直接替换整个HttpHeaders对象，会覆盖Tracing拦截器注入的头信息。应使用add或addAll方法追加自定义头：

// 错误示例：覆盖所有头信息，丢失TraceId相关头
restClient.get()
        .uri("/api/service")
        .headers(headers -> headers.setAll(customHeaders))
        .retrieve();

// 正确示例：保留原有头，追加自定义配置
restClient.get()
        .uri("/api/service")
        .headers(headers -> headers.addAll(customHeaders))
        .retrieve();

4. 确认Tracing配置是否开启 #

检查配置文件中的Tracing开关是否正确启用：

management:
  tracing:
    enabled: true
    propagation:
      type: tracecontext

同时排查是否有自定义配置类无意中禁用了RestClient的Tracing拦截器。

5. 排查自定义拦截器顺序问题 #

如果存在自定义请求拦截器，需确保Trace拦截器优先执行，避免自定义逻辑修改或移除Tracing头。可通过显式添加顺序来保证：

@Bean
public RestClient restClient(TraceRestClientInterceptor traceInterceptor, ClientHttpRequestInterceptor customInterceptor) {
    return RestClient.builder()
            .requestInterceptor(traceInterceptor) // 先执行Trace拦截器
            .requestInterceptor(customInterceptor)
            .build();
}

若以上步骤无效，可开启Tracing debug日志追踪头信息传递情况：

logging:
  level:
    io.micrometer.tracing: DEBUG
    org.springframework.cloud.sleuth: DEBUG

内容的提问来源于stack exchange，提问作者Ashley James