requests.Session()默认连接池maxsize=10、block=False，易因连接耗尽抛MaxRetryError；需通过HTTPAdapter显式配置pool_maxsize、pool_block等参数并mount生效。
requests.Session() 默认连接池怎么配置才不踩坑
默认情况下 requests.Session() 用的是 urllib3.PoolManager，但它的连接池参数是隐藏的——你不显式配置，就只能靠默认值硬扛。常见问题比如「并发一高就报 ConnectionError: Max retries exceeded」，其实是底层连接池满 + 重试策略叠加导致的。
-
maxsize默认是 10，意味着单个 host 最多复用 10 个连接；如果发往同一个域名（如api.example.com）的请求超过这个数，后续请求会排队或新建连接（取决于block设置） -
block=True才会让新请求阻塞等待空闲连接；默认是False，此时直接抛MaxRetryError - 要改必须通过
mount注入自定义HTTPAdapter，不能直接改 Session 实例属性
import requests from urllib3.util import Retrysession = requests.Session() adapter = requests.adapters.HTTPAdapter( pool_connections=10, # host 级别连接池数量（影响 mount 的 key） pool_maxsize=20, # 单 host 最大连接数 max_retries=Retry( total=3, backoff_factor=0.3, allowed_methods={"GET", "POST"} ), pool_block=True # 关键：让请求排队而不是立刻失败 ) session.mount("https://", adapter) session.mount("http://", adapter)
asyncio + httpx 怎么做真正的并发限流
用 asyncio.gather() 直接扔几百个 httpx.AsyncClient().get() 请求，很容易触发服务端限流或本地文件描述符耗尽。真正可控的并发得靠信号量（asyncio.Semaphore）或 httpx.LimitPool。
-
httpx.LimitPool是更轻量的选择，它限制的是「同时发起的请求数」，不关心连接复用 - 如果还要控制每秒请求数（QPS），得自己套一层时间窗口计数器，
httpx不内置令牌桶 - 注意
httpx.AsyncClient实例本身不是线程安全的，但可在单个协程内复用；不要在多个 task 里共享未加锁的 client
import asyncio import httpxsem = asyncio.Semaphore(10) # 同时最多 10 个请求
async def fetch(url): async with sem: async with httpx.AsyncClient() as client: return await client.get(url, timeout=5)
urls = ["https://www.php.cn/link/5f69e19efaba426d62faeab93c308f5c"] 50 results = await asyncio.gather([fetch(u) for u in urls])
requests + threading 混用时连接池失效的真实原因
很多人以为开了 20 个线程、每个线程 new 一个 requests.Session() 就能并发 20，结果发现 QPS 上不去甚至比单线程还慢——根本原因是每个 Session 都有独立连接池，而目标服务端对单 IP 的并发连接数有限制（比如 Nginx 的 limit_conn），大量短生命周期 Session 还会导致 TIME_WAIT 堆积。
立即学习“Python免费学习笔记（深入）”；
- 线程间复用同一个
Session是危险的（Session不是线程安全的） - 正确做法是每个线程持有一个专属
Session，且提前配置好连接池（见第一个副标题），并确保长期复用（比如用线程局部存储threading.local） - 更稳妥的替代方案是改用
concurrent.futures.ThreadPoolExecutor+ 预热好的 Session 实例池
别把连接池和业务限流混为一谈
连接池管的是「TCP 连接复用与数量上限」，限流管的是「单位时间内允许多少次请求」。前者是客户端资源管理，后者是服务端契约或反爬策略。你配了 pool_maxsize=100，不代表你能每秒发 100 个请求——如果目标接口要求每分钟最多 60 次，你还硬发，照样被 429 Too Many Requests。
- 遇到
429，优先检查响应头里的Retry-After或自定义限流字段，而不是调大连接池 - 业务限流建议用
ratelimit这类库做装饰器级控制，或者在请求前加time.sleep()计算间隔（简单场景） - 连接池调太大反而可能触发服务端连接拒绝（如某些云 API 对单 IP 连接数硬限制）
连接池参数和业务限流策略得分开设计，而且都要根据实际压测结果调，不是堆数字就能解决问题。
