API经常超时，怎样分别记录连接等待、首Token与完整响应时间？

记录连接建立首字节与流结束时间

适用于请求很久没有首字节、流式输出开始后卡住，或高并发时偶尔超时的应用。保留安全请求标识和分阶段时间，确认浏览器、网关及后台哪个先中止。用户界面等待结束不代表服务已经取消，后台可能仍处理，需要将客户端状态和服务执行状态分开记录。

区分连接读取写入和连接池等待

分别检查连接超时和读取等待配置，再核对写入及连接池等待的限制，再核对代理和服务端限制。观察SDK是否重试造成总时长超出预期。流式心跳只能说明连接有活动，不等于业务结果完成；首字节很快也可能后续输出极慢，不能只统计连接时间当成模型完整推理时长。

按阶段设置超时并保留总预算

为不同阶段设置符合环境的超时，同时保留整次任务的总时长预算。短期网络故障可按规则有限重试，长任务可使用服务支持的异步或流式方式，但应用需要正确显示进度。涉及外部写入时先查状态或使用幂等，不把客户端超时直接当作服务完全没有执行。

验证慢请求及中断后的真实状态

用可控测试环境检查慢连接、慢响应和流中断，确认错误类型及任务状态准确，并验证达到预算会停止等待。比较完整耗时与各阶段记录，避免重试被隐藏。成功应是用户得到真实结果或明确失败，而不是只消除超时提示；部分输出和未知业务状态都不能误报完成。

本文没有制造外部超时或调用付费服务，也没有提供一组通用于所有网络的秒数。HTTP客户端与SDK对超时定义不同，应查实际版本。无限延长等待会占用资源，提前取消也需要服务支持；无法确认远端操作结果时，应保留未知状态并继续核查，不能凭异常名称推断。