Requests请求超时必须显式设置，否则默认无限等待导致卡死；推荐用元组timeout=(connect, read)如(3,10)，并结合urllib3.Retry实现带退避的可控重试。
Requests请求超时直接报错，必须显式设置timeout
Requests默认不设超时，网络卡住或服务无响应时会无限等待，生产环境绝对不能接受。必须在每次requests.get()、requests.post()等调用中传入timeout参数，否则不是“可能超时”，而是“一定会卡死”。
推荐写法是同时指定连接超时和读取超时：timeout=(3, 10)——第一个数字是建立TCP连接的上限（通常1–5秒），第二个是接收响应体的上限（根据接口预期响应时间定，一般5–30秒）。只写一个数字如timeout=10，表示两者共用该值，容易误判：比如3秒连上了但后7秒卡在传输大文件，实际已超出合理等待范围。
常见错误现象：requests.exceptions.Timeout抛出时没捕获，导致整个程序中断；或把timeout设成None以为“不限时”很安全，实则埋下雪崩隐患。
单次超时不等于失败，用urllib3.util.Retry做可控重试
Requests内置了重试机制，但默认关闭。别急着装retrying库（已停止维护且不兼容Python 3.12+），直接用Requests底层依赖urllib3的Retry类更轻量、更可控。
关键点：
-
status_forcelist=[429, 502, 503, 504]：只对这些HTTP状态码重试，避免对400/401这类客户端错误反复白费力气 -
backoff_factor=1：第一次重试延迟1秒，第二次2秒，第三次4秒……指数退避防打爆下游 - 必须搭配
HTTPAdapter挂载到session，不能只改单次请求
示例：
from requests import Session from urllib3.util.retry import Retrysession = Session() retry_strategy = Retry( total=3, status_forcelist=[429, 502, 503, 504], backoff_factor=1 ) adapter = HTTPAdapter(max_retries=retry_strategy) session.mount("http://", adapter) session.mount("https://", adapter)
后续所有 session.get() / session.post() 都自动带重试
response = session.get("https://www.ufcn.cn/link/46b315dd44d174daf5617e22b3ac94ca", timeout=(3, 10))
重试不是万能的，要区分超时类型再决定是否重试
ConnectionTimeout（连不上）和ReadTimeout（连上了但读不完）语义不同，盲目重试可能加重问题。
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
比如：
- 对CDN节点的
ConnectTimeout重试有意义——换节点可能就通了 - 但对自身网络出口故障导致的持续
ConnectTimeout，重试只是徒增日志噪音 - 对上游API返回
503 Service Unavailable重试合理；但若它明确返回429 Too Many Requests且Header里有Retry-After，就得按Header指示休眠，而不是硬套固定backoff_factor
所以真实项目里，建议捕获requests.exceptions.Timeout后，检查exception.request的URL和上下文，再决定是立即重试、降级返回缓存，还是直接上报告警。
超时与重试组合使用时，总耗时 = 单次timeout × 重试次数 + 退避延迟
这点极易被忽略：设了timeout=(3, 10)、total=3、backoff_factor=1，最坏情况总耗时接近(3+10)×3 + (1+2+4) = 46秒。如果上层接口SLA要求P99
因此必须根据业务场景反推参数：
- 支付回调类强实时接口：单次
timeout=(2, 3)，total=1，不重试，失败走人工补单 - 后台数据同步任务：可接受延迟，
timeout=(5, 30)，total=3，配合backoff_factor=2 - 永远不要让重试后的总等待时间超过调用方能容忍的上限
线上出问题时，第一反应不该是“加retry次数”，而是查监控确认是偶发抖动还是持续性故障——后者加再多重试也没用。