最直接有效的规避方式是减少静态方法的使用，把逻辑移到可实例化、可注入的对象中；通过接口+依赖注入替代静态工具类、为遗留静态调用添加轻量封装层、升级mockito启用inline模式，以及警惕“静态即工具”的惯性思维，将隐含状态或外部依赖的静态方法抽象为可替换组件。
最直接有效的规避方式是减少静态方法的使用，把逻辑移到可实例化、可注入的对象中。静态方法本身不可替换、不可重写，天然阻碍隔离测试——这不是测试工具的缺陷，而是设计上的耦合信号。
用接口+依赖注入替代静态工具类
把原本分散在 Utils 类里的静态方法，提取成接口并提供默认实现：
- 定义接口：
interface IdGenerator { String generate(); } - 实现真实逻辑：
class UuidGenerator implements IdGenerator { public String generate() { return UUID.randomUUID().toString(); } } - 被测类通过构造函数接收该接口：
public class OrderService { private final IdGenerator idGen; OrderService(IdGenerator idGen) { this.idGen = idGen; } }
测试时只需传入一个返回固定字符串的模拟实现，完全绕开 PowerMock 或 mockito-inline。
对遗留静态调用做轻量封装层
无法一次性重构全部代码时，可在静态调用点外加一层薄薄的实例包装：
- 新增一个非静态服务类：
class StaticWrapper { public boolean isNullOrEmpty(List> list) { return Objects.isNull(list) || list.isEmpty(); } } - 原业务代码改调用该实例方法，而非直接调用
CollectionUtils.isEmpty()等静态方法 - 测试中可轻松
@Mock这个 wrapper，无需准备类、无需特殊 runner
升级 Mockito 并启用 inline 模式（适用于新项目）
若必须保留部分静态方法且使用较新版本（Mockito ≥ 3.4.0），可启用原生支持：
- Maven 中添加：
<dependency><groupid>org.mockito</groupid><artifactid>mockito-inline</artifactid><scope>test</scope></dependency> - 测试中直接使用：
try (MockedStatic<math> mocks = mockStatic(Math.class)) { mocks.when(() -> Math.random()).thenReturn(0.5); assertEquals(0.5, Math.random(), 0.01); }</math> - 注意：此方式需确保 JVM 参数未禁用 inline agent，且不兼容某些安全策略严格的运行环境
警惕“静态即工具”的惯性思维
很多静态方法其实隐含状态或外部依赖（如时间、随机数、配置读取），它们并不真正“无状态”：
-
TimeUtil.now()实际依赖系统时钟 → 应抽象为Clock接口 -
ConfigUtil.get("db.url")依赖环境变量或配置文件 → 应由配置服务统一注入 - 一旦识别出这类“伪静态”，就自然明确了该抽离为可替换组件的方向
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
