超时与取消设计要点
每次调用都要有明确超时并支持取消：连接、首 token、总时长三段时间分开设置，因为它们的失败含义不同。用户关闭页面或点击停止时，取消要沿调用链传到上游，否则请求继续跑、资源与费用照扣。超过同步窗口的任务应转异步，别让用户盯着一个可能超时的页面。
基本信息
| 分级超时 | 连接超时、首 token 超时、总时长分开设置 |
|---|---|
| 取消传播 | 用户中断后取消请求链上游，并停止计费统计 |
| 记录 | 超时与取消分开统计，混在一起看不出真实故障率 |
| 长任务 | 超过同步窗口转异步任务，返回任务标识供轮询 |
| 默认值 | 宁短勿长：先设保守值，按 P99 实测再放宽 |
典型使用场景
- 流式生成：首 token 超时短、总时长可长，用户能尽早判断是否继续等
- 工具调用链路：每个工具单独设超时，避免一个慢工具拖住整条链
- 批量任务：单条超时即标记失败并继续，不阻塞整批
- 用户主动取消：前端停止按钮要真正中断后端，而不是只隐藏输出
- 值班排障：按超时类型分别告警，快速区分网络问题与上游变慢
超时配置示例
超时配置示例
connect_timeout: 3s # 建连阶段，网络问题为主
first_token_timeout: 10s # 首 token，判断上游是否卡住
total_timeout: 90s # 总时长上限，含重试
取消: 客户端断开即中止请求并同步取消上游调用
超时处理: 记指标、给用户可重试提示、不静默吞掉异常三个阶段的口径建议
| 阶段 | 建议口径 | 异常表现 |
|---|---|---|
| 连接 | 数秒级，短于后端建连耗时上限 | 建连失败或网络不可达 |
| 首 token | 十秒上下，可按模型与任务调整 | 上游排队或推理堆积 |
| 总时长 | 按任务类型定，长任务转异步 | 整体生成超时 |
| 重试总预算 | 小于用户可接受的等待时间 | 重试把等待时间拉长到不可用 |
超时值要与上游的服务等级匹配：客户端超时短于上游正常响应时间，会造成大量假超时与无谓重试。