Spring Reactor Context究竟是什么？其底层是否基于ThreadLocal实现？

首先明确结论：Reactor Context 完全不依赖 ThreadLocal 实现上下文传递，它是一套和响应式序列深度绑定的独立机制，从设计上就规避了ThreadLocal在响应式场景下的诸多问题。

核心工作机制 #

• 上下文与响应式链绑定
  当你通过Mono#contextWrite或Flux#contextWrite添加上下文时，这个上下文会成为当前响应式操作符节点的一部分，形成一个包含上下文信息的新操作符链。上下文本身是不可变的键值对集合，类似线程安全的Map，后续操作可以读取或扩展它，但不会修改原始上下文。

• 订阅阶段的上下文传播
  响应式序列的执行是从下游订阅发起的，上下文会沿着订阅链反向传递（从订阅端向上游操作符传递）。每个操作符节点在初始化时都会接收并保存这个上下文，确保整个链上的所有操作都能访问到统一的上下文数据。

• 线程切换时的上下文携带
  当使用subscribeOn或publishOn切换线程时，Reactor的调度器（Scheduler）会负责将当前上下文"携带"到新线程中。具体来说，调度器在提交任务时，会把上下文和任务逻辑打包在一起，当任务在新线程执行时，会先将上下文设置为当前执行环境的上下文，执行完后再恢复原有环境——整个过程不需要依赖ThreadLocal，完全由Reactor内部的执行机制管控。

为什么不用ThreadLocal？ #

在响应式编程场景中，一个线程可能同时处理多个不同的响应式序列请求，ThreadLocal的线程绑定特性会导致上下文污染；而且线程切换频繁时，手动维护ThreadLocal的设置、清理逻辑极易出错。Reactor Context是和具体的响应式链绑定的，每个链拥有独立的上下文，不同请求之间不会互相干扰，天然适配响应式编程的并发模型。

简单示例验证 #

Mono.just("hello")
    .contextWrite(ctx -> ctx.put("userId", "u_001"))
    .map(content -> {
        // 读取上下文
        String userId = Context.current().get("userId");
        return content + ", user: " + userId;
    })
    .publishOn(Schedulers.boundedElastic()) // 切换到新线程
    .subscribe(System.out::println); // 输出: hello, user: u_001

即便切换了线程，代码依然能正确获取到上下文里的userId，这就是Reactor Context跨线程传递的效果。

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