静态变量破坏单元测试隔离性：其跨测试保留状态导致结果不可靠、无法mock、增加清理负担且引发并发问题；应改用实例变量+依赖注入实现可测性。
静态变量会直接破坏单元测试的隔离性。每个测试用例本应独立运行、互不干扰，但静态变量在类加载后就常驻内存，值会跨测试用例保留——前一个测试对它的修改，会直接影响后一个测试的结果。
导致测试结果不可靠
比如一个计数器静态变量 static int callCount，测试 A 执行后将其设为 5；测试 B 期望初始值为 0，却读到 5，断言失败。这种“状态污染”让测试偶然失败，难以复现，也掩盖真实逻辑缺陷。
阻碍模拟与替换
静态方法或依赖静态变量的逻辑，无法被 Mockito 等主流框架轻松 mock。你不能替换成假实现，也不能控制其返回值，只能真实调用——这意味着测试可能访问数据库、发 HTTP 请求或读取文件，违背了单元测试“快速、确定、隔离”的基本原则。
增加测试准备与清理负担
- 必须在每个测试前后手动重置静态变量（如
callCount = 0），容易遗漏 - 使用
@BeforeClass和@AfterClass也仅限于整个测试类级别，无法支持单个测试粒度的隔离 - 并发执行测试时，多个线程共享同一静态变量，重置操作本身还可能引发竞态
替代方案更利于测试
把状态从静态改为实例持有，就能自然融入依赖注入和 mock 流程：
- 将静态工具类改造成 Spring Bean 或普通服务类，通过构造函数或 setter 注入
- 用接口定义行为，测试时注入模拟实现（
new MockCounter()） - 配置类中的常量仍可用
public static final，但运行时可变状态坚决不放 static
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
