java中static变量不支持天然隔离，单元测试易因共享状态导致污染、不可预测及并行失败；应通过解耦、threadlocal、实例字段或mockstatic等策略规避，而非依赖事后清空。
Java 中 static 变量本身不支持天然隔离，单元测试时若直接依赖或修改它，极易造成测试间状态污染、结果不可预测、并行执行失败等问题。关键不是“测完再清空”，而是从设计和测试策略上规避共享状态——让 static 变量不参与可变逻辑，或确保每次测试拥有独立上下文。
重构：让 static 变量退出业务流程
静态字段一旦用于控制分支、缓存运行时数据或保存环境配置（如 public static String env = "dev"），就会破坏测试的确定性。应主动解耦：
- 将静态配置转为构造参数或方法参数，例如把
Processor.process(data)改为Processor.process(data, config) - 用不可变对象替代可变静态字段，如声明
private static final Config DEFAULT_CONFIG = new Config("prod") - 对第三方 SDK 的静态调用，封装一层实例代理类，把
SDK.doXxx()转为sdkClient.doXxx()，便于在测试中替换
替代方案：用 ThreadLocal 实现线程级隔离
当确实需要“全局但需隔离”的上下文（如请求 traceId、用户租户信息），ThreadLocal 是比 static 更安全的选择。JUnit 默认为每个 @Test 方法启动新线程（取决于测试运行器），天然适配：
- 声明为
private static final ThreadLocal<string> traceId = ThreadLocal.withInitial(() -> UUID.randomUUID().toString());</string> - 测试前通过
traceId.set("test-001")注入可控值 - 测试后务必调用
traceId.remove()，防止内存泄漏（尤其在并行测试中）
测试类内：禁用可变 static 字段
在测试类中定义 static List<string> logs = new ArrayList()</string> 是典型陷阱——它跨所有测试方法共享，导致断言失败或误报：
- 一律改用实例字段：
private List<string> logs;</string> - 配合
@BeforeEach初始化：@BeforeEach void init() { logs = new ArrayList(); } - 仅允许
static final常量存在，如测试模板字符串、复用的断言工具方法
不得已时：Mockito mockStatic 精准控制
若无法重构且必须验证含 static 方法/变量的行为，可用 Mockito 5.0+ 的 mockStatic 进行有限模拟：
- 用 try-with-resources 确保自动清理：
try (MockedStatic<utils> mocked = mockStatic(Utils.class)) { ... }</utils> - 只 mock 当前测试所需行为，例如
mocked.when(() -> Utils.getTimeout()).thenReturn(1000) - 避免在多个测试中重复 mock 同一类型；更推荐将 static 调用提取为可注入依赖
不复杂但容易忽略：真正稳定的单元测试，从来不是靠“清空 static”来补救，而是从第一行代码就拒绝让可变 static 深度介入核心逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
