直接修改连接池参数可缓解但不解决根本问题，溢出本质是并发控制缺失和会话生命周期管理混乱；aiohttp默认limit=100、limit_per_host=100易因未限并发、重复创建session、多子域分散连接等导致耗尽。
直接改连接池参数就能缓解，但不解决根本问题——溢出本质是并发控制缺失和会话生命周期管理混乱。
为什么aiohttp.ClientSession默认配置容易触发连接池溢出
aiohttp的ClientSession内部使用TCPConnector管理连接池，默认limit=100、limit_per_host=100，看似宽松，但实际中常因以下原因快速耗尽：
- 多个协程同时调用
session.get()，而未限制并发数，瞬间打满连接池 - 每个
ClientSession实例都维护独立连接池，若在循环里反复创建ClientSession（比如每个请求都新建），连接不会复用，且旧会话未close()就丢弃，导致连接泄漏 - 目标域名多、分散（如采集不同子域），
limit_per_host形同虚设，总连接数仍受limit约束，但被均摊后单主机可用连接反而不足
必须设置的TCPConnector关键参数
不要依赖默认值。初始化ClientSession时，显式传入定制的TCPConnector：
推荐生产环境配置（对应“生产环境高并发”场景）：
立即学习“Python免费学习笔记（深入）”；
-
limit=100：全局最大空闲+活跃连接总数 -
limit_per_host=30：单个主机（含端口、协议）最多保持30个连接，防止单站点占满池子 -
keepalive_timeout=30：连接空闲30秒后自动关闭，避免长连接堆积 -
force_close=False：允许连接复用；设为True会每次请求后强制关连接，完全失去池化意义
示例代码片段：
connector = aiohttp.TCPConnector(
limit=100,
limit_per_host=30,
keepalive_timeout=30,
force_close=False
)
async with aiohttp.ClientSession(connector=connector) as session:
# 后续所有请求复用该连接池
用BoundedSemaphore控制并发请求数
连接池参数管的是“能开多少连接”，而asyncio.BoundedSemaphore管的是“同一时刻最多发几个请求”。两者必须配合，否则光调大limit只是把溢出延迟到更晚，还可能压垮目标服务。
- 信号量数量建议 ≤
limit_per_host× 主机数（保守起见，可设为limit_per_host本身） - 务必在
async with semaphore:块内发起请求，不能只包await response.text()这种后续操作 - 若使用
asyncio.gather()批量提交任务，需确保每个任务都持有信号量，否则gather本身不阻塞，并发仍失控
错误示范：await asyncio.gather(*[fetch(url) for url in urls]) —— 没控并发
正确做法：在fetch()内部加async with semaphore:
最容易被忽略的资源泄漏点
连接池溢出常伴随“看不见”的泄漏，调试时难定位：
-
ClientSession未用async with或忘记await session.close()：会话对象销毁时，底层连接不会立即释放，尤其在异常提前退出时 - 协程抛出未捕获异常后中断，导致
async with上下文没走完__aexit__，连接滞留 - 使用
asyncio.create_task()启动后台请求但未保存引用，Task被GC前连接池无法回收关联资源
验证是否泄漏：程序运行稳定后，执行asyncio.all_tasks()检查是否存在长期pending状态的Task，再查其协程是否卡在session.get()等I/O上。
