static变量在分布式单例环境中是进程级共享且无租户隔离，易导致跨租户数据污染；应通过InheritableThreadLocal、ConcurrentHashMap+tenantId键、显式传参等方式替代，并配合静态扫描与运行时兜底检查。
直接定位问题根源：static 变量在分布式单例环境（如 Spring Bean、Lambda 执行环境、线程池复用场景）中是进程级共享的，不具备租户边界。一旦某个租户写入，后续任意租户线程都可能读到残留值——这不是并发 bug，是设计误用。
第一步：快速识别 static 变量污染点
重点扫描以下三类代码位置：
- 所有 public static 字段，尤其是 String、Map、List、Object 类型，特别警惕命名含 “context”“holder”“cache”“config”的类
- Spring 中声明为 @Component @Scope("singleton") 的 Bean 内部的非 final 静态字段或可变实例字段（如未加 synchronized 或 volatile 的计数器、状态标记）
- Lambda 函数中定义的模块级变量（Java 的 static、Python 的 module-level dict、Node.js 的 global 对象属性），尤其在 Init 阶段初始化、Invoke 阶段复用的场景
第二步：验证是否已发生数据残留
不依赖日志回溯，用最小成本现场验证：
- 在关键业务入口（如 Controller 方法开头）插入断点或日志：打印 Thread.currentThread().getId() + " | tenant=" + TenantContext.getCurrentTenant() + " | staticValue=" + YourClass.STATIC_FIELD
- 发起两个不同租户的请求（A 和 B），观察 B 请求中是否输出了 A 租户写入的 static 值
- 若出现“租户B执行时看到租户A的 static 值”，即确认污染；此时再检查该 static 字段是否被用于构造 SQL、缓存 key、权限判断等敏感路径
第三步：修复与加固策略
不是简单删掉 static，而是按场景替换为安全替代方案：
-
租户上下文传递：改用 InheritableThreadLocal
封装 tenantId，并确保在 Filter/Interceptor 的 finally 块中调用 remove()（防止线程池复用污染） - 运行时配置或缓存：避免 static Map 存租户配置，改用 ConcurrentHashMap + tenantId 作为 key；或接入 Redis，key 强制拼接 tenant:{id}:config
- 无状态计算逻辑：将原 static 工具类方法改为普通实例方法，通过 Spring 管理其生命周期；或彻底函数化，所有依赖参数显式传入（tenantId 必须作为入参）
第四步：上线前必做防御性检查
静态扫描 + 运行时兜底，双保险防漏网：
- 用 SonarQube 或自定义 Checkstyle 规则，禁止在项目中新增 public static 非常量可变字段
- 在全局异常处理器中增加检测：若发现当前线程中 TenantContext.getCurrentTenant() 为空，但后续业务又访问了本应带租户隔离的数据源，立即抛出 TenantContextMissingException 并告警
- 对所有数据库查询启用 Hibernate Filter 或 MyBatis-Plus 多租户插件，确保即使上下文丢失，SQL 层仍强制追加 WHERE tenant_id = ?
