第三方接口调用异常需分层兜底：在HTTP客户端、RPC层等调用点附近封装统一远程调用模板并转为自定义业务异常，配合Feign降级、Dubbo Filter拦截，最终统一接入全局异常处理器返回503/500，并增强可观测性。
第三方接口调用异常的兜底，不能简单套用 Controller 层的全局异常处理器（如 @RestControllerAdvice 或 FastAPI 的 @app.exception_handler），因为这类异常通常发生在业务逻辑层、服务层甚至远程调用链路中（如 HTTP 客户端、Feign、Dubbo、OpenFeign、Ribbon 等），根本不会到达 MVC 的 DispatcherServlet 或 FastAPI 的路由分发环节。
明确异常发生位置，才能精准兜底
第三方调用异常一般出现在以下环节：
- HTTP 客户端层面（如 RestTemplate、OkHttp、FeignClient、HttpClient）抛出的
IOException、TimeoutException、ConnectException、SocketTimeoutException - 反序列化失败引发的
JsonProcessingException、SerializationException - 响应状态码非 2xx（如 401/403/502/503/504）但未主动校验，导致后续空指针或类型转换异常
- 下游返回格式异常（如本该是 JSON 却返回 HTML 错误页），触发解析失败
- Dubbo/Feign 的 RPC 层异常（如
RpcException、RemoteAccessException）
分层兜底：在调用点附近做第一道防护
不要指望“全局”一次兜住所有第三方异常——它必须前置到调用发起处，否则异常可能已污染业务上下文或造成资源泄漏。推荐做法：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 封装统一的远程调用模板（如
RemoteClient），内部对常见网络异常、超时、状态码做标准化处理，并统一转为自定义业务异常（如ThirdPartyUnavailableException） - 使用
try-catch包裹关键调用，但仅限于这一层；捕获后不吞异常，而是重抛语义清晰的异常，交由上层（如 Service）或全局处理器二次处理 - 对 FeignClient，可通过
@FeignClient(fallback = XxxFallback.class)配置降级类，实现熔断+兜底响应 - 对 Dubbo，可配置
filter（如前文提到的DubboExceptionFilter），在 provider/consumer 侧统一拦截并封装
与全局异常体系对齐：让第三方异常“归队”
兜底不是掩盖问题，而是让异常进入已有治理链路。关键动作：
- 所有远程调用抛出的异常，最终应统一转为项目定义的异常基类（如 SpringBoot 中的
AppException，FastAPI 中继承HTTPException或自定义BaseException） - 在全局异常处理器中，显式注册对第三方异常子类的处理（如
@ExceptionHandler(ThirdPartyTimeoutException.class)），返回503 Service Unavailable或500并附带可读提示（如“上游服务暂不可用，请稍后重试”） - 对兜底的
@ExceptionHandler(Exception.class)，务必加日志记录完整堆栈 + 请求上下文（traceId、第三方服务名、URL、耗时），但响应体绝不暴露技术细节
增强可观测性：兜底不是终点，而是起点
真正的兜底能力体现在事后可定位、可复盘：
- 记录调用指标：成功率、P99 耗时、错误码分布（可用 Micrometer + Prometheus 实现）
- 对高频失败的第三方接口，自动触发告警（如 5 分钟内超时率 > 5%）
- 在日志中打标
remote_call=true、target_service=pay-center，便于 ELK 快速聚合分析 - 必要时在兜底响应中返回唯一请求 ID（如
x-request-id），方便上下游协同排查
