tcpconnector(limit=100)不能防崩，因limit仅限制并发tcp连接数而非请求速率，易致任务积压、内存飙升、服务端限流；需协同配置limit、limit_per_host和keepalive_timeout，并配合semaphore等前置限速。
为什么 TCPConnector(limit=100) 不能直接防崩
因为 limit 控制的是「同时打开的 TCP 连接数」，不是「每秒请求数」或「并发任务数」。你用 asyncio.create_task() 启动 1000 个请求，它们会立刻排队进连接池——只要池里有空位（比如 limit=100），就立即发出去；没空位就等。但等待本身不降低压力，反而可能积压大量 pending task，内存涨、超时多、服务端看到的是密集短连接或复用不足的长连接。
-
limit不限制协程创建速度，只限底层 socket 并发数 - 如果目标服务器对单 IP 有连接复用要求（如 HTTP/2 或 keep-alive 效果差），
limit高反而触发对方限流或 reset - 默认
limit_per_host=100，但若你请求 10 个不同子域（a.example.com / b.example.com），实际可能打开 1000 个连接——limit是全局的，limit_per_host才是按域名隔离的
真正起作用的三个关键参数怎么配
光调 limit 没用，得组合控制：连接总量、单主机上限、空闲连接保活。否则容易出现「看着没超限，但服务器已拒绝新连接」。
-
limit=50：设低一点，比如 30–80，别迷信 100；多数 API 网关对单客户端连接数软限制在 50 左右 -
limit_per_host=10：强制分散到各 host，避免打爆某一个子域名后影响其他请求 -
keepalive_timeout=30：设短些（默认 60s），让空闲连接更快释放，腾出 slot 给新请求；太长会导致连接堆积，尤其服务端主动 close 时 aiohttp 还在傻等
示例：
connector = aiohttp.TCPConnector(
limit=50,
limit_per_host=10,
keepalive_timeout=30,
force_close=False # 默认 False，设 True 会禁用 keep-alive，一般不用
)
并发太高时，错误现象和对应排查点
不是所有报错都叫“连接被拒绝”，要结合日志看本质：
-
ClientOSError: [Errno 24] Too many open files：系统级文件描述符耗尽，说明limit设太高 + 未及时 close session，需检查是否漏了await session.close()或没用async with session: -
ServerDisconnectedError：服务端主动断连，常见于连接复用失败或请求间隔太短，此时要降limit_per_host+ 加随机 jitter 延迟 -
TimeoutError（非asyncio.TimeoutError）：通常是连接池满且无空闲连接可用，排队超时；这时不是加limit，而是加队列控制或限速
比 connector 更有效的限流手段在哪里
连接池只是最后一道闸门，真要稳，得在发起请求前就控速。aiohttp 自身不带限流器，得靠外部协调：
- 用
asyncio.Semaphore(20)包住整个session.request()调用，这才是控制「并发请求数」最直接的方式 - 对同一 host 的请求，用
aiolimiter或自定义令牌桶，做 QPS 级别限制（比如 10 req/s），比连接数更贴近业务水位 - 别忽略 DNS 解析瓶颈：
resolver默认用系统阻塞式 resolver，高并发下会卡住；换成aiohttp.AsyncResolver或aiodns
示例 Semaphore 用法：
sem = asyncio.Semaphore(20) <p>async def fetch(url): async with sem: # 这里卡住，直到有许可 async with session.get(url) as resp: return await resp.text()</p>
连接池参数只是表层，真正的压测水位和熔断逻辑得落在业务层调度上；很多人调完 limit 就以为万事大吉，结果上线后发现错误日志里全是 ServerDisconnectedError，却还在翻 connector 文档——那多半是漏了对 host 粒度的控制或没加请求级限速。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
