requests的timeout参数必须设为元组形式timeout=(connect_sec, read_sec)，其中connect_sec控制DNS、TCP、TLS等连接阶段（建议3–5秒），read_sec控制响应体接收时间（建议10–30秒），避免单值timeout导致误判。
requests 的 timeout 参数不是“总耗时限制”，而是两个独立阶段的上限：连接建立时间 + 响应读取时间。不区分设置，很容易在慢网络或高延迟服务下误判超时。
requests.get() 的 timeout 元组怎么填才不踩坑
直接写 timeout=10 看似简单，但实际会把连接和读取绑死在同一时限里——比如 DNS 解析慢、TLS 握手卡顿，哪怕后续响应很快，也会被一并截断。
更稳妥的做法是拆成元组：timeout=(connect_sec, read_sec)：
-
connect_sec控制 DNS 查询、TCP 连接、TLS 握手全过程，建议设为 3–5 秒（公共 API 可放宽到 7） -
read_sec控制从服务器开始发第一个字节到接收完全部响应的时间，要按业务预期响应体大小和带宽估算，通常 10–30 秒较合理 - 避免设
connect_sec过小（如0.5），否则在移动网络或弱 DNS 环境下会高频触发ConnectTimeout - 不要设
read_sec为0或负数，requests会静默忽略并退化为无读取超时
asyncio.wait_for() 会自动取消协程，但 cancel() 不一定立即生效
用 asyncio.wait_for(coro(), timeout=5) 能中断挂起的协程，但前提是目标协程本身支持取消（即内部有可中断的 await 点）。
常见陷阱：
立即学习“Python免费学习笔记（深入）”；
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 如果协程里写了
time.sleep(10)（同步阻塞），wait_for触发 cancel 后，它仍会卡满 10 秒才退出 - 用
asyncio.sleep()替代，或确保所有 I/O 操作（如aiohttp.ClientSession.get()）都带自己的timeout参数 - 某些底层库（如旧版
aioredis）的 cancel 支持不完整，需查文档确认 cancelability - cancel 后若没
await coro或asyncio.shield()保护，可能抛出CancelledError并中断当前作用域
socket.setdefaulttimeout() 影响全局，慎用于混合场景
调用 socket.setdefaulttimeout(5) 会修改所有后续创建的 socket 实例的默认行为，包括 urllib、ftplib、甚至部分数据库驱动的底层连接。
这在单任务脚本里没问题，但在以下情况极易出问题：
- Web 服务（如 Flask/FastAPI）中混用 requests 和自定义 socket，导致 HTTP 客户端也受干扰
- 多线程环境里，一个线程改了全局 timeout，另一个线程的 socket 行为意外变化
- 依赖长连接的协议（如 MQTT、WebSocket）被强制断开
- 更安全的替代方案：显式传参，比如
socket.socket().settimeout(5)，或优先走requests/aiohttp等封装好的库
重试机制必须配合超时，且跳过确定性失败
单纯加 retry 不解决根本问题；如果每次请求都因证书错误或 404 而失败，重试只会放大延迟和日志噪音。
用 urllib3.Retry 配置时注意：
- 只对
ConnectTimeout、ReadTimeout、ConnectionError（非证书类）等临时性错误重试 - 明确排除
CertificateError、InvalidURL、TooManyRedirects—— 这些是配置或逻辑错误，重试无意义 -
backoff_factor建议设为 0.3～0.5，避免短时间密集重试压垮下游 - 重试总耗时 = Σ(各次 timeout × 重试次数)，别让重试叠加后远超业务容忍阈值
