Brave Tracing currentSpan为null：测试与Maven构建结果不一致

核心问题分析 #

你遇到的情况是：Service通过构造函数注入Tracing对象后，调用tracing.tracer().currentSpan()在Eclipse单独运行测试时正常，但执行mvn clean install构建时返回null。这通常是测试执行环境、Spring上下文或Span上下文传播的差异导致的。

可能的原因 #

• 测试上下文污染：Maven批量执行测试时，多个测试类共享Spring上下文，可能导致ThreadLocal存储的Span上下文未被正确清理。
• Span未主动绑定：单独测试时可能有隐式的Span触发（如请求拦截器、注解自动生效），但批量构建时配置未触发Span启动。
• 线程上下文未传播：如果Service使用异步线程，Span的ThreadLocal上下文未传递到异步线程中。
• 依赖版本不一致：Eclipse和Maven依赖解析的版本差异，导致Tracing框架的上下文绑定逻辑异常。

可行解决方案 #

1. 测试中手动启动并绑定Span #

在测试方法内主动创建Span并绑定到当前线程，确保Service调用时存在有效Span：

@Test
public void testServiceOperation() {
    Tracer tracer = tracing.tracer();
    // 启动Span并绑定到当前线程
    try (Span span = tracer.startSpan("test-service-span")) {
        tracer.withSpan(span);
        // 调用Service方法
        yourService.targetMethod();
    }
}

如果使用OpenTelemetry，也可以直接给测试方法或Service方法添加@WithSpan注解，自动触发Span创建。

2. 确保测试上下文干净 #

在测试类上添加@DirtiesContext注解，强制每个测试方法执行后重置Spring上下文，避免上下文污染：

@RunWith(SpringRunner.class)
@SpringBootTest
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
public class YourServiceTest {
    // 测试代码
}

3. 检查Tracing配置的初始化时机 #

确保SpanHandler在Tracer初始化完成前被添加，避免上下文绑定逻辑失效：

@Configuration
public class TracingConfiguration {
    @Bean
    public Tracing tracing() {
        return Tracing.newBuilder()
                .addSpanHandler(new CustomSpanHandler())
                .build();
    }

    @Bean
    public Tracer tracer(Tracing tracing) {
        return tracing.tracer();
    }
}

避免在@PostConstruct中动态添加SpanHandler，除非能保证在所有Service初始化前执行。

4. 验证依赖一致性 #

执行mvn dependency:tree命令，检查Tracing相关依赖（如opentelemetry-api、opentelemetry-sdk、spring-cloud-sleuth等）的版本是否统一，排除冲突依赖。如果Eclipse使用的是本地缓存版本，可执行mvn clean install -U强制更新依赖。

5. 处理异步线程的上下文传播 #

如果Service中使用异步线程，需要用Tracing框架提供的线程包装器传递Span上下文：

// 以OpenTelemetry为例，包装线程池
ExecutorService tracedExecutor = OpenTelemetryContextWrapper.wrap(Executors.newFixedThreadPool(5));

// 提交任务时自动传播Span上下文
tracedExecutor.submit(() -> {
    // 异步操作逻辑
});

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