requests默认不设超时，易导致请求无限挂起；必须显式设置connect和read超时，并通过自定义HTTPAdapter挂载到Session，同时配置Retry策略覆盖超时异常。
为什么 requests 默认超时行为不靠谱
requests 库默认不设超时，requests.get("https://example.com") 可能卡住几分钟甚至更久，尤其在 DNS 解析失败、服务器无响应或网络中间设备丢包时。这不是“慢”，而是彻底挂起——线程阻塞、协程无法调度、服务假死。必须显式控制连接建立和读取两个阶段的耗时。
用 urllib3 的 Timeout 配置适配器
requests 的底层是 urllib3，真正生效的超时控制得落在 HTTPAdapter 上。直接传 timeout 参数只影响单次请求，而自定义适配器能统一管控所有请求（包括重试、重定向中的子请求）。
关键点：
-
urllib3.util.Timeout支持细粒度：用connect控制 TCP 握手+DNS 时间，read控制响应体接收时间 - 别用
Timeout.DEFAULT_TIMEOUT，它仍是None；必须显式传数字或Timeout(connect=5, read=10) - 适配器要挂载到 session，不是单个 request
from requests.adapters import HTTPAdapter from urllib3.util.timeout import Timeout import requests <p>session = requests.Session() adapter = HTTPAdapter( pool_connections=10, pool_maxsize=10, max_retries=2, timeout=Timeout(connect=3.0, read=8.0) # ← 这行无效！timeout 不是 HTTPAdapter 参数 )</p><h1>正确写法：在 send() 调用时传 timeout，或改用 mount + 自定义 PoolManager</h1><p>
立即学习“Python免费学习笔记（深入）”；
正确注册带超时的适配器（绕过 timeout 参数陷阱）
HTTPAdapter 构造函数根本没有 timeout 参数——文档里写的 “timeout” 是误导。真正生效的方式是：在 send() 内部由 urllib3 的 PoolManager 读取配置，而 requests 把这个逻辑藏在了 urllib3.PoolManager 实例化时。所以得自己构造带 timeout 的 manager。
实操建议：
- 继承
HTTPAdapter，重写init_poolmanager方法，传入自定义timeout - 连接超时建议 ≤ 3s（DNS+TCP），读取超时按业务容忍度设（API 通常 5–15s）
- 避免设成相同值，比如
connect=5, read=5，否则 DNS 卡 4.9s 后只剩 0.1s 读响应，大概率失败
from requests.adapters import HTTPAdapter
from urllib3.poolmanager import PoolManager
from urllib3.util.timeout import Timeout
<p>class TimeoutHTTPAdapter(HTTPAdapter):
def <strong>init</strong>(self, *args, *<em>kwargs):
self.timeout = kwargs.pop("timeout", Timeout(connect=3.0, read=8.0))
super().<strong>init</strong>(</em>args, **kwargs)</p><pre class="brush:php;toolbar:false;">def init_poolmanager(self, *args, **kwargs):
kwargs["timeout"] = self.timeout
return super().init_poolmanager(*args, **kwargs)session = requests.Session() session.mount("http://", TimeoutHTTPAdapter(timeout=Timeout(connect=2.5, read=6.0))) session.mount("https://", TimeoutHTTPAdapter(timeout=Timeout(connect=2.5, read=6.0)))
超时后重试策略必须同步调整
单纯加超时不够——如果第一次请求因网络抖动超时，直接抛异常就丢了重试机会。但默认 Retry 不感知超时类型，connect 和 read 超时都算作 ReadTimeoutError 或 ConnectTimeoutError，需显式加入 retry 策略。
注意：
-
urllib3.Retry的retry_on_status不管超时，得用retry_on_exception - 推荐组合：
connect失败重试（DNS/防火墙问题可能瞬时恢复），read超时慎重试（可能服务端已处理但回包慢） - 重试间隔用指数退避，避免雪崩；总重试次数别超过 3 次
完整示例里，max_retries 必须配合 Retry 对象，且明确包含 ReadTimeoutError 和 ConnectTimeoutError。
超时值不是越小越好，也不是写死一个数就能一劳永逸。connect 和 read 分开设、适配器挂载方式不对、重试没覆盖超时异常——这三处最容易漏，一漏就让超时配置形同虚设。
