Java中深度Mock未知RPC接口的核心是将RPC调用抽象为普通Java接口后用Mockito精准模拟其行为；只要接口定义在classpath下可见，即可Mock方法签名、异常、多次调用、参数验证及延迟响应，无需RPC框架启动。
Java 中对未知 RPC 接口做深度 Mock 测试，核心不是“绕过 RPC 协议”，而是**把 RPC 调用抽象成普通 Java 接口后，再用 Mockito 精准模拟其行为**。Dubbo、gRPC 等框架在客户端侧最终都表现为本地接口（如 UserService 或 OrderService），只要拿到接口定义（哪怕没有实现类），就能 Mock。
明确 RPC 接口的 Java 形态
RPC 的本质是远程调用，但开发时你依赖的从来不是网络层，而是服务提供方发布的Java 接口契约。比如 Dubbo 服务：
- Dubbo 消费方通过
@DubboReference注入的是一个本地代理对象，类型就是接口（如PaymentService） - 这个接口本身不包含 RPC 实现细节，只声明方法签名——它和普通本地接口完全一致
- 只要该接口在测试 classpath 下可见（通常由 provider 的 API module 提供），Mockito 就能 mock 它
不依赖 Spring 容器的纯 Mock 方式
避免启动整个 Dubbo 或 gRPC 客户端，直接在单元测试中构造 Mock 对象：
- 用
Mockito.mock(PaymentService.class)创建接口 Mock 实例 - 用
when(mock.pay(anyString(), anyDouble())).thenReturn(true)打桩返回值 - 将该 Mock 实例传给被测业务类（通过构造函数或 setter 注入）
- 无需任何 RPC 配置、注册中心、序列化器——彻底隔离外部依赖
覆盖真实 RPC 的典型行为模式
深度 Mock 不只是返回固定值，还要模拟 RPC 常见场景：
立即学习“Java免费学习笔记（深入）”；
-
异常分支：用
when(mock.queryOrder("123")).thenThrow(new RpcException("timeout")) -
多次调用不同响应：用
thenReturn("first", "second", "third")模拟重试或分页 -
验证调用次数与参数：用
verify(mock, times(2)).pay(eq("order-001"), gt(0.0)) -
延迟响应（模拟网络耗时）：用
thenAnswer(invocation -> { Thread.sleep(200); return "ok"; })
对接真实 Dubbo/gRPC 场景的注意事项
若测试类使用了 Spring 上下文（如 @SpringBootTest），需防止真实 RPC Bean 被自动注入：
- 加
@MockBean替代@Autowired，让 Spring 容器注入 Mock 实例 - 或在测试配置中排除 RPC 自动装配（如
@ImportAutoConfiguration(exclude = DubboAutoConfiguration.class)） - 确保接口 jar 已引入 test scope，且未被
provided或runtime作用域屏蔽
本质上，Mockito 并不关心接口背后是本地调用还是 RPC 调用——它只认 Java 类型。只要接口存在、方法可访问，Mock 就成立。关键在于把 RPC 当作“契约接口”来对待，而非“黑盒网络服务”。
