Dubbo超时不能靠try-catch“伪装”成功，必须通过容错降级（fallback）实现；推荐使用@DubboReference(fallback=XXX.class)配置降级类，或结合本地缓存提升伪装合理性，避免在provider端处理及非幂等操作。
Dubbo服务调用超时时，不能靠try-catch直接“伪装”返回值——因为超时异常（如 org.apache.dubbo.remoting.TimeoutException）发生在RPC通信层，客户端线程已收到失败响应，catch住异常后只能做降级处理，而非让调用“看起来成功”。真正的“本地伪装”，本质是**容错降级（fallback）**，需结合Dubbo的容错机制实现，try-catch仅作为兜底或辅助手段。
使用Dubbo内置fallback机制（推荐）
Dubbo原生支持服务降级，无需手动try-catch，更可靠、可配置、易维护：
- 在消费者端接口上添加
@DubboReference(fallback = XxxFallback.class)，其中XxxFallback实现该接口，返回预设的模拟数据（如空对象、默认值、缓存快照等） - fallback类必须是无参构造、public、且实现同一接口；Dubbo会在超时、网络异常、provider不可用时自动调用它
- 也可通过XML或application.properties全局配置默认fallback策略，例如：
dubbo.consumer.fallback=mock（需自定义MockInvoker）
在业务代码中用try-catch做轻量级降级
适用于简单场景或已有逻辑无法改造为fallback类的情况，但要注意：超时异常类型需准确捕获，且不能掩盖真实错误：
- 捕获具体异常：优先 catch
org.apache.dubbo.remoting.TimeoutException和org.apache.dubbo.rpc.RpcException（其cause可能为TimeoutException） - 避免裸catch Exception：否则会吞掉NPE、业务异常等，导致问题难排查
- 示例：
try {<br> Result result = userService.queryById(123);<br> return result;<br>} catch (RpcException e) {<br> if (e.getCause() instanceof TimeoutException) {<br> log.warn("UserService timeout, use local mock", e);<br> return new User().setId(123).setName("mock_user"); // 本地伪装<br> }<br> throw e; // 其他Rpc异常不降级<br>}
配合本地缓存提升伪装合理性
纯硬编码mock数据体验差，建议搭配缓存增强“伪装”的可信度：
立即学习“Java免费学习笔记（深入）”；
- 调用前先查本地缓存（如Caffeine），命中则直接返回，规避远程调用；未命中再发起Dubbo调用
- 调用超时后，可尝试刷新缓存（异步）、或返回缓存中的旧数据（stale-while-revalidate模式）
- 注意缓存过期策略与业务一致性要求匹配，避免返回严重过时信息
避免常见误区
几个容易踩坑的点：
- 不要在provider端try-catch超时：超时是consumer端感知的，provider无感知，也无法“假装成功”
- 不要用Thread.sleep()模拟超时测试：Dubbo超时由Netty/Client连接层控制，sleep无法触发真实TimeoutException
- fallback/mock逻辑必须幂等、无副作用：不能写DB、发MQ，否则降级时重复执行引发数据异常
