Spring 不提供“反向委派”机制，实际是开发者用 ThreadLocal 在请求线程中绑定用户变量（如 UserInfo），通过拦截器设置与清理，确保线程安全和请求级隔离。
Spring 框架本身不提供“反向委派”这一标准术语，也不存在官方定义的“线程上下文加载用户定义变量类”的机制。但结合实际开发场景，你提到的很可能是指：在 Spring 管理的线程（如 Web 请求线程）中，将用户自定义的对象（如 User、Tenant、TraceId 等）临时绑定到当前线程，并在后续调用链中安全获取——即基于 ThreadLocal 的上下文透传。这不是 Spring 容器主动“加载类”，而是开发者主动利用线程局部存储实现上下文托管。
为什么不是 Spring “加载”变量类？
Spring 的 ApplicationContext 负责 Bean 的生命周期管理，它加载的是配置中声明的、被容器托管的组件（如 @Service、@Component）。而用户登录后产生的 User 对象、请求级别的 TenantContext 或 RequestMetadata，通常：
- 不在 Spring 配置中声明为单例或原型 Bean（否则会跨请求共享，引发线程安全问题）
- 不通过 @Autowired 注入，而是由拦截器、过滤器或 AOP 在请求入口处动态创建并绑定
- 其生命周期与 HTTP 请求/线程强绑定，需手动清理，避免内存泄漏
典型实现方式：ThreadLocal + 工具类封装
这是最常用、最轻量、也最可控的方式。核心是定义一个静态 ThreadLocal 容器，存放用户自定义类型实例：
- 定义上下文持有类（泛型支持任意类型）：
public class RequestContext<T> { private static final ThreadLocal<Object> contextHolder = new ThreadLocal<>(); public static <T> void set(T value) { contextHolder.set(value); } public static <T> T get() { return (T) contextHolder.get(); } public static void remove() { contextHolder.remove(); } } - 在登录成功或请求预处理时设置：
RequestContext.set(new UserInfo(userId, username, roles)); - 在任意后续业务层直接获取：
UserInfo user = RequestContext.get(); // 线程内始终可用 - 务必在 Filter 或 Interceptor 的 finally 块中调用
remove()，防止线程复用导致脏数据
与 Spring 生命周期协同的关键点
虽然 ThreadLocal 是手动管理，但可与 Spring 机制自然融合：
-
配合 HandlerInterceptor：在
preHandle中 set，在afterCompletion中 remove，确保每次请求闭环 - 配合 OncePerRequestFilter：比普通 Filter 更可靠，天然保证每个请求只执行一次，适合做上下文初始化和清理
- 避免注入 Spring Bean 到 ThreadLocal 对象中：ThreadLocal 存的是运行时实例，不是 Spring Bean；若需访问 Service，应通过 ApplicationContextAware 获取上下文再 getBean，而非把 Service 实例塞进 ThreadLocal
- 注意异步场景：CompletableFuture、@Async、线程池任务会丢失主线程的 ThreadLocal 值，需显式传递或使用 TransmittableThreadLocal（阿里 TTL 库）
不推荐的“伪反向委派”误区
有些开发者试图让 Spring 容器“感知”并自动管理 ThreadLocal 变量，例如：
- 把 ThreadLocal 包装成 @Component 并设为 @Scope("prototype") —— 无效，prototype 只控制 Bean 创建次数，不解决线程隔离
- 在 @PostConstruct 中初始化 ThreadLocal —— 错误时机，此时不是请求线程，且只执行一次
- 依赖 Spring 的 RequestContextListener —— 它仅对 ServletRequestAttributes 生效，不适用于自定义对象
这些做法混淆了容器作用域与线程作用域，反而增加复杂度和风险。
