Spring Boot中Request Scope作用域是否完全线程安全？

你的实现在标准Spring Web MVC同步请求处理流程中是线程安全的，但并非100%无风险，存在几个容易触发线程安全问题/数据错乱的边界场景。

为什么常规场景下是安全的 #

• 你给AuthContext配置的@RequestScope(proxyMode = ScopedProxyMode.TARGET_CLASS)是Spring请求作用域的标准用法：Spring会为每个HTTP请求创建独立的AuthContext实例，绑定到当前请求线程的ThreadLocal中。其他组件注入的其实是该类的CGLIB代理对象，所有方法调用都会自动路由到当前线程绑定的真实实例，不同请求的实例完全隔离，不会出现属性跨请求覆盖的问题。
• 你在Controller入口方法第一行就调用setContext给当前实例的三个请求级属性赋值，后续整个同步执行的请求链路（Controller、Service、DAO等逻辑）中，所有组件拿到的都是当前请求专属的AuthContext实例，读写操作不会互相干扰。

存在的风险场景（这些场景下会出线程安全/数据错乱问题） #

• 异步逻辑场景直接失效：如果你在请求处理中使用了异步逻辑（包括@Async注解、手动创建子线程、线程池提交任务、CompletableFuture异步编排），子线程不会继承父线程的请求作用域上下文，此时在子线程中注入AuthContext读取属性，要么抛找不到上下文的异常，要么拿到其他请求绑定的实例，导致数据串流。
• 提前读取会出现空指针：你是在Controller方法内手动给三个属性赋值，如果有组件在请求进入Controller之前就尝试读取AuthContext里的属性（比如自定义Filter、Interceptor、全局参数解析器、全局异常处理器中提前调用），会因为还没执行赋值逻辑拿到null值。
• 响应式栈完全不兼容：如果你用的是Spring WebFlux而非传统的Spring MVC，请求处理和线程不是一一绑定的，基于ThreadLocal实现的请求作用域会完全失效，会出现严重的上下文错乱问题。

优化建议 #

• 把AuthContext的属性初始化逻辑从Controller移到自定义的Filter/HandlerInterceptor中，请求刚进入服务端时就完成属性赋值，从根源上避免提前读取的空指针问题。
• 涉及异步逻辑时，不要直接在子线程中注入AuthContext取值，要在提交异步任务前手动把当前上下文的属性值取出来，作为参数传递给异步任务使用。
• 如果是响应式技术栈，不要用ThreadLocal绑定的请求作用域Bean存上下文，改用Reactor原生的Context机制存储请求级数据。

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