关键在于显式控制租户上下文生命周期：必须在请求入口set、出口finally中remove；异步任务需手动透传并隔离；自定义TenantScope替代RequestScope；配套清理验证机制保障无泄漏。
关键不在“存”，而在“谁来管生命周期”——ThreadLocal 本身不负责清理，它只提供线程隔离的容器；真正决定租户上下文是否残留的，是开发人员对绑定与解绑时机的显式控制。
租户上下文必须绑定到请求边界，而非线程边界
在 Web 场景中，HTTP 请求天然具有明确的开始与结束。不能依赖线程池中线程的自然销毁（线程复用下永远不会销毁），而应把租户 ID 的 set 和 remove 严格放在请求入口和出口处：
- 在网关过滤器（如 Spring Gateway 的 GlobalFilter）或 Servlet Filter 的 doFilter 中调用
TenantContext.set(tenantId) - 务必在 finally 块 中执行
TenantContext.remove()，确保即使发生异常也能清理 - 避免在 Controller 或 Service 层手动 set/remove —— 这会导致职责错位、遗漏风险高
异步任务必须主动透传并隔离租户上下文
@Async、定时任务、消息监听器等脱离 HTTP 生命周期的场景，ThreadLocal 不会自动继承，更不会自动清除：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 启动异步任务前，显式获取当前租户 ID：
String tenantId = TenantContext.get() - 将 tenantId 作为参数传入异步方法，并在方法开头立即
TenantContext.set(tenantId) - 异步方法结尾或 finally 中调用
TenantContext.remove() - 若使用 CompletableFuture，需配合
copy或自定义ThreadLocal透传逻辑（例如用Supplier封装带上下文的 callable）
用自定义 Scope 替代 RequestScope 管理租户级 Bean
Spring 的 @RequestScope 依赖 Servlet 容器的请求生命周期，在离线任务、MQ 消费等非 Web 场景下失效：
立即学习“Java免费学习笔记（深入）”；
- 定义
@TenantScope注解，配合自定义Scope实现类，内部基于 ThreadLocal 存储 bean 实例映射 - 通过 AOP 在目标方法执行前调用
TenantScope.open(tenantId)，执行后调用close() - 每个租户的 bean 实例独立缓存，避免跨租户污染，且能随
TenantContext.remove()触发回收
清理动作要可感知、可验证、可兜底
remove() 不是“写了就一定生效”，尤其在线程池复用场景下，需配套机制保障：
- ThreadLocal 的 value 若为复杂对象（如数据库连接、缓存句柄），应在 remove 前触发其 close/dispose 逻辑
- 在应用启动时注册 JVM Shutdown Hook，强制清空所有已知租户上下文（用于应急）
- 提供运维端点（如
/actuator/tenant-context）返回当前线程中活跃的租户 ID 和关联资源数，便于诊断泄漏 - 定期扫描线程池中空闲线程的 ThreadLocalMap，对超过阈值未清理的租户条目发出告警
