timeout=(3, 10)中第一个数字控制连接超时（TCP握手完成前），第二个控制读取超时（等待响应首字节）。单数字timeout=5等价于(5,5)，生产环境易出问题。
timeout=(3, 10) 中两个数字分别控制什么
第一个是连接超时（connect timeout），即 TCP 握手完成、建立连接前等待的最大时间；第二个是读取超时（read timeout），指连接建立后，等待服务器返回**第一个字节**的时间（不是整个响应体下载完的时间）。
常见误解是认为第二个参数控制“整个请求耗时”，其实不是——一旦开始接收数据，后续的传输（比如大文件分块接收）就不再受这个读取超时约束，除非你手动设置 stream=True 并逐块调用 response.iter_content()，否则默认行为只卡在“等首字节”这一步。
- 若 DNS 解析慢或目标 IP 不可达，
connect timeout会先触发 - 若服务端卡在业务逻辑（如数据库查询未返回 HTTP 响应头），
read timeout会触发 - 若服务端已发响应头但发响应体极慢（例如流式接口每秒只吐 1B），默认不超时；加
stream=True后需自行对每次iter_content()调用设超时
不写元组、只写单个数字会发生什么
传一个数字（如 timeout=5）等价于 timeout=(5, 5)，即连接和读取共用同一阈值。这看似省事，但在生产中容易出问题：
- 内网调用通常连接极快（timeout=3 会误杀合法请求
- 公网调用连接可能因网络抖动达 2s，若
read timeout也只设 2s，留给业务处理的时间几乎为零 - 某些代理或负载均衡器会在连接建立后延迟转发，导致“连接快、读取慢”，单值 timeout 无法精细区分
requests 里 timeout 不生效的几种真实情况
超时参数只作用于 requests 底层的 socket 级操作，以下场景它管不了：
立即学习“Python免费学习笔记（深入）”；
- DNS 解析超时：Python 默认使用系统 getaddrinfo，不受
timeout控制；需配合dnspython或自定义 resolver 才能干预 - SSL 握手耗时：TLS 协商阶段计入连接超时，但若证书链验证复杂或 OCSP 响应慢，可能突破设定值（尤其在旧版 OpenSSL 上）
- 重定向跳转：每次跳转都重新走一遍连接+读取流程，
timeout对每跳单独生效，不是总耗时限制 - Response.content 解析：拿到响应体后调用
.json()或.text触发的编码解码、JSON 解析失败，完全不走 timeout 机制
更稳妥的超时组合建议
没有万能值，但可按场景参考：
- 内网微服务调用：
timeout=(0.5, 3)—— 连接必须快，业务允许稍长 - 公网第三方 API：
timeout=(3, 15)—— 容忍网络波动，但防服务端 hang 死 - 上传大文件（
files=...）：timeout=(5, 60)—— 发送请求体本身不被 read timeout 管，但服务端处理可能卡住，需拉长 read 值 - 绝对不能容忍延迟的健康检查：
timeout=(1, 1)+allow_redirects=False
真正难处理的是“既要低延迟又要高成功率”的场景——这时候 timeout 只是第一道防线，后面还得配熔断（tenacity）、降级、异步重试，单纯调数字解决不了根本问题。
