显式捕获受检异常是构建稳定支付容错链的关键起点，需按语义区分可重试（如IOException）、不可重试（如IllegalArgumentException）及需降级（如AlipaySystemErrorException）三类异常，并在签名、请求、解析、确认等关键节点细粒度捕获与策略化重试。
显式捕获受检异常是构建稳定支付容错链的关键起点。它强制你在编译期就处理可能失败的环节，避免运行时突然崩溃；而多点重试不是简单地“失败就再试一次”，而是针对不同异常类型、不同调用位置（如签名生成、http请求、响应解析、结果确认）分别设计可重试性判断和退避策略。核心在于：受检异常帮你守住入口，多点重试帮你稳住全程。
明确区分可重试与不可重试的受检异常
支付链路中常见的受检异常需按语义归类，不能一概而论：
-
可重试异常：如
IOException（网络中断、连接拒绝）、SocketTimeoutException（读写超时）、SSLHandshakeException（握手临时失败）——本质是瞬态通信问题，重试大概率成功 -
不可重试异常：如
IllegalArgumentException（商户号/金额格式错误）、SignatureException（签名密钥不匹配或过期）、InvalidParameterException（参数校验不通过）——属于业务逻辑或配置错误，重试只会重复失败，甚至触发风控 -
需降级兜底的异常：如
AlipaySystemErrorException（支付宝返回 SYSTEM_ERROR）、WechatPayException（微信返回 INVALID_REQUEST）——服务端内部错误，应记录并走备用通道或异步补偿
在关键节点嵌入带上下文的显式捕获
不要只在最外层 try-catch。应在支付流程的每个独立动作处做细粒度捕获，并携带当前阶段标识：
- 签名生成阶段：捕获
InvalidKeyException、SignatureException，立即终止流程并告警，不重试 - HTTP请求发送阶段：捕获
IOException及其子类，启动指数退避重试（如初始延迟 500ms，最多 3 次） - 响应体解析阶段：捕获
JsonProcessingException或自定义的ResponseParseException，若因字段缺失导致解析失败且确认是对方接口变更，则跳过该次重试，直接降级 - 结果确认阶段（如查询订单状态）：捕获超时或空响应，允许最多 2 次轻量重试（延迟固定 1s），避免阻塞主流程
用责任链模式串联多点重试逻辑
把支付流程拆成「准备→请求→解析→确认」四个处理器，每个处理器实现自己的异常捕获与重试策略：
- 每个处理器接收统一的
PaymentContext对象，含重试计数、当前阶段、原始请求参数 - 处理器内部用
try-catch显式捕获对应受检异常；若判定可重试，更新 context 中的重试次数并返回 “RETRY” 状态，由调度器决定是否继续执行本节点 - 不可重试异常直接抛出，交由上层统一降级（如返回“支付处理中，请稍后查看”）
- 例如：HTTP 请求处理器捕获到第 2 次
SocketTimeoutException后，自动将超时时间从 8s 提升至 15s，再发起第 3 次请求
配合幂等控制与可观测性落地
多点重试必须以业务幂等为前提，否则一次支付可能被多次扣款：
- 所有重试请求必须携带相同且全局唯一的
out_trade_no和request_id - 每次重试前记录日志：「[阶段=REQUEST][重试序号=2][异常=SocketTimeoutException][延迟=1000ms]」
- 暴露指标：各阶段重试次数、重试成功率、因不可重试异常终止的占比，用于快速定位薄弱环节
- 当某商户连续 5 分钟内因同一类异常触发重试超过阈值，自动熔断该商户通道，转人工核查
