在编写单元测试时，如果被测逻辑依赖一个嵌套静态类，比如某个工具类内部的静态配置对象或静态工厂方法，很多人会发现传统的mock方法根本不起作用。这是因为静态成员属于类本身而非实例，Mockito的核心机制是动态代理，天然只作用于实例方法。本文将系统讲解如何在Java中模拟嵌套静态类，包括Mockito-inline的静态Mock用法、PowerMock方案，以及更推荐的重构解耦思路。
一、先厘清嵌套静态类的本质
Java中的嵌套类分为两类：静态嵌套类和内部类。静态嵌套类通过static关键字修饰，定义形如OuterClass.StaticNestedClass，它不持有外部类的隐式引用，编译后实际上是一个独立的字节码文件，类名通常是OuterClass$StaticNestedClass。正因为它是独立加载的类，模拟它和模拟一个普通类在字节码层面没有本质区别。
内部类则不同，它隐式持有外部类实例的引用，模拟时需要先构造外部实例。混淆这两者往往导致测试代码出现编译错误或运行时的空指针异常。先看一段被测代码的示例：
public class OrderService {
// 嵌套静态类，持有远程调用逻辑
public static class RemoteClient {
public String queryUser(String userId) {
// 实际会发起HTTP请求
return "real-user-" + userId;
}
}
public String getUserName(String userId) {
RemoteClient client = new RemoteClient();
return client.queryUser(userId);
}
}上面的代码里，getUserName方法内部直接new了一个静态嵌套类实例。要让单测不发出真实请求，必须对这个依赖进行处理，这正是Mock要解决的问题。
二、使用Mockito-inline模拟静态嵌套类
从Mockito 3.4开始，官方引入了mockStatic能力，5.x版本后已内置在核心包中，无需额外引入PowerMock。如果使用Mockito 4.x及更早版本，需要引入mockito-inline依赖替代默认的mockito-core：
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-inline</artifactId>
<version>4.11.0</version>
<scope>test</scope>
</lt;dependency>注意上面的XML最后一行应为</dependency>，实际编写时请保证标签闭合。引入依赖后，模拟嵌套静态类的实例方法与模拟普通类完全一致，因为静态嵌套类编译后就是独立类：
@Test
void testGetUserName() {
// 直接mock静态嵌套类，语法与普通类相同
OrderService.RemoteClient mockClient = mock(OrderService.RemoteClient.class);
when(mockClient.queryUser("1001")).thenReturn("mock-user");
OrderService service = new OrderService() {
// 生产代码中通常通过构造器或setter注入，这里演示覆盖
};
// 如果被测代码内部new了对象，需要配合mockConstruction
try (MockedConstruction<OrderService.RemoteClient> construction =
mockConstruction(OrderService.RemoteClient.class,
(mock, context) -> when(mock.queryUser(any())).thenReturn("mock-user"))) {
String result = service.getUserName("1001");
assertEquals("mock-user", result);
}
}mockConstruction是Mockito-inline提供的关键能力，它能拦截new关键字的对象创建过程，把内部new出来的实例替换为Mock对象。对于嵌套静态类同样适用，只要传入完整的类引用OrderService.RemoteClient.class即可。
如果嵌套静态类中包含静态方法，则需要使用mockStatic，并且必须放在try-with-resources中，确保Mock作用域结束后自动解除，否则会污染其他测试用例：
try (MockedStatic<OrderService.RemoteClient> mockedStatic =
Mockito.mockStatic(OrderService.RemoteClient.class)) {
mockedStatic.when(() -> OrderService.RemoteClient.loadConfig())
.thenReturn("fake-config");
assertEquals("fake-config", OrderService.RemoteClient.loadConfig());
}三、PowerMock方案及适用场景
对于仍在维护老项目、测试框架锁定JUnit 4的团队，PowerMock仍是常见选择。PowerMock通过自定义类加载器和字节码改写，可以模拟静态方法、构造函数甚至private方法。模拟静态嵌套类的关键在于PrepareForTest注解中要写外部类，而不是嵌套类本身：
@RunWith(PowerMockRunner.class)
@PrepareForTest({OrderService.class})
public class OrderServiceTest {
@Test
public void testWithPowerMock() throws Exception {
OrderService.RemoteClient mockClient = PowerMockito.mock(OrderService.RemoteClient.class);
PowerMockito.whenNew(OrderService.RemoteClient.class).withNoArguments().thenReturn(mockClient);
when(mockClient.queryUser(anyString())).thenReturn("powermock-user");
OrderService service = new OrderService();
assertEquals("powermock-user", service.getUserName("1001"));
}
}这里有个高频踩坑点：whenNew拦截不到时，绝大多数原因是PrepareForTest里没有把定义该嵌套类的那个外部类加进去。因为new指令发生在外部类的方法体中，字节码改写必须作用于外部类。
PowerMock的缺点也很明显：它对JUnit版本、Mockito版本有严格的配套要求，与JaCoCo覆盖率统计经常冲突，而且在JUnit 5上支持不完善。除非历史包袱无法摆脱，否则新项目应优先选择Mockito-inline。
四、更优雅的替代思路：重构解耦
无论是静态Mock还是字节码改写，本质上都是在测试中对抗语言的静态绑定机制，这类测试往往脆弱且难以理解。更工程化的做法是通过依赖注入把嵌套静态类的使用变成可替换的接口：
public class OrderService {
public interface UserClient {
String queryUser(String userId);
}
public static class RemoteClient implements UserClient {
@Override
public String queryUser(String userId) {
return "real-user-" + userId;
}
}
private final UserClient client;
public OrderService(UserClient client) {
this.client = client;
}
public String getUserName(String userId) {
return client.queryUser(userId);
}
}改造后，测试中只需传入一个Mock的UserClient，完全不依赖任何Mock框架的高级特性。这种写法让被测类的依赖显式化，提高了代码的可测性，也符合控制反转的设计原则。
总结一下选型建议：新项目优先重构解耦，实在无法改动生产代码时使用Mockito-inline的mockStatic和mockConstruction，老项目维持PowerMock但逐步迁移。模拟嵌套静态类并不难，难的是判断什么情况下应该Mock、什么情况下应该重构，希望本文的方案对比能帮你做出合适的取舍。