超时是生产环境的底线要求，需分connect和read两阶段独立设置，配合熔断降级、异步分层控制及结构化监控告警。
Python调用外部接口时，不设超时等于裸奔——网络抖动、服务卡顿、对方无响应，都可能让你的程序卡死、线程堆积、资源耗尽。合理设置超时，不是“以防万一”，而是生产环境的底线要求。
超时不是只写 timeout=5 就完事
requests 库的 timeout 参数实际包含两个阶段：连接超时（connect）和读取超时（read）。只传一个数字（如 timeout=5），等价于 timeout=(5, 5)，但两者语义不同、应独立控制：
- connect 超时：TCP 握手+SSL 协商完成前的最大等待时间，建议设为 2~3 秒。太长会拖慢失败判定，太短易在弱网下误判
- read 超时：服务器返回首字节后，接收完整响应的最长等待时间，需结合业务预期响应时长设定（如普通查询 5 秒、导出任务 60 秒）
推荐显式写成元组：requests.get(url, timeout=(3, 10))，可读性高，也方便后续按场景动态调整。
别让单个请求拖垮整个服务
超时只是第一道防线；真正保护系统，得靠熔断+降级+限流组合策略：
立即学习“Python免费学习笔记（深入）”；
- 用 tenacity 或 pydantic 配合 retrying 实现指数退避重试（最多 2 次，间隔 0.5s→1s），避免雪崩式重试
- 引入 circus 或 sentinel-python 做失败率熔断（例如 5 分钟内错误率超 50%，自动切断该接口调用 60 秒）
- 对非核心接口（如埋点上报、日志推送），直接设为“尽力而为”：超时即丢弃，不重试、不报错、不阻塞主流程
异步场景下 timeout 更要分层控制
用 aiohttp 或 httpx.AsyncClient 时，timeout 不仅作用于单次请求，还需配合 asyncio 的 wait_for 做外层兜底：
- 底层 client 设置
timeout=aiohttp.ClientTimeout(total=8, connect=2, sock_read=6) - 外层用
asyncio.wait_for(task, timeout=10)，防止 DNS 解析卡住、事件循环异常等 client 层无法捕获的挂起 - 注意：aiohttp 的
total和wait_for时间不能简单叠加，建议外层 timeout 比 client 总超时多 1~2 秒作为缓冲
监控和告警必须跟上超时行为
光设了超时没用——你得知道它什么时候被触发、为什么触发：
- 记录每次请求的 实际耗时、是否触发超时、走的是 connect 还是 read 超时
- 聚合统计：按接口维度看超时率趋势，突增说明下游异常或自身网络问题
- 对高频超时接口，自动触发告警并附带最近 5 条超时详情（URL、耗时、状态码、trace_id）
- 不要只记 error 日志——超时本身是预期行为，应归类为 warn 级别，但需结构化字段便于检索分析
超时不是性能优化技巧，而是稳定性基建。它不解决根本故障，但能阻止小问题演变成大事故。
