超时是大规模请求下的常态，需通过精准捕获超时异常、分级多通道降级、熔断控制与可观测性闭环，保障系统可用性。

在大规模请求场景下，超时不是小概率事件，而是系统常态。关键不在于“避免超时”，而在于让系统在超时发生时，不卡死、不降级失败，而是自动切到另一条可用路径——这需要捕获特定运行时异常，并基于异常类型精准触发分支切换。

识别并隔离超时异常

超时异常需与其他错误（如格式错误、认证失败）明确区分开。不能笼统 catch Exception，必须捕获具体类型：

• HTTP 客户端：捕获 TimeoutException 或状态码为 408 / 504 的响应
• 大模型 API：识别返回中含 "timeout"、"request timed out" 的 error 字段，或响应耗时 > 阈值（如 30s）
• 数据库连接池：捕获 SQLTimeoutException 或连接获取超时（如 HikariCP 的 Connection acquisition timeout）

配置多通道切换策略

单一备用通道不可靠，应设计分级降级链。例如主用 GPT-4 → 备用 Claude → 最终兜底本地规则引擎：

• 首次超时：重试本通道（最多 1 次），间隔 1.5 秒，避免瞬时抖动误判
• 连续两次超时：切换至备用模型（如 Claude），同时上报指标（如 fallback_to_claude_count）
• 备用通道也超时或报错：启用轻量级兜底逻辑（如关键词匹配 + 模板填充），确保有响应
• 所有通道失败：返回结构化错误码（如 ERR_CHANNEL_EXHAUSTED）和用户友好提示

避免雪崩与状态污染

自动切换不是无代价的，必须加控制阀：

• 对每个备用通道设置独立熔断器（如 1 分钟内失败率 > 50% 则临时禁用该通道）
• 记录每次切换的原始请求 ID、耗时、目标通道，便于事后归因
• 禁止在重试/切换逻辑中修改原始请求上下文（如 mutate request body），防止脏数据透传
• 超时阈值需按通道动态调整（GPT-4 设为 30s，Claude 可设为 45s，本地引擎设为 800ms）

验证与可观测性闭环

切换逻辑上线前必须可验证，上线后必须可追踪：

• 在测试环境注入可控超时（如 Mock 服务固定延迟 35s），验证是否准确进入 Claude 分支
• 生产中埋点：统计各通道成功率、平均耗时、切换触发次数，绘制热力图
• 告警联动：当某通道切换率突增 3 倍，自动触发对上游依赖（如模型 API SLA）的健康检查
• 日志中标记关键字段：channel=main|fallback=claude|retry=1|trace_id=xxx，支持快速回溯