根本原因是asyncio并发过高导致文件描述符耗尽：每个未复用的http连接占用一个fd，而ulimit -n默认1024，aiohttp默认连接池无上限且session未复用或未显式关闭，dns/ssl/time_wait状态socket持续占fd，最终触发emfile错误。
根本原因不是 Python 写错了，而是 async 代码在没节制地开 socket——每个未复用的 HTTP 连接都占一个文件描述符（fd），asyncio 并发一高，ulimit -n 默认值（通常是 1024）几秒就爆了。
为什么 asyncio.run() + aiohttp.ClientSession() 还会触发 EMFILE？
aiohttp 默认的 ClientSession 虽然带连接池，但池子大小是动态的，且默认不设上限；如果你在循环里反复创建 session（比如每个请求都 new 一个），或没显式 await session.close()，fd 就不会释放。更隐蔽的是：DNS 查询、SSL 握手失败重试、TIME_WAIT 状态的 socket，在内核里仍算“打开”，持续占 fd。
- 别在 for 循环里写
async with aiohttp.ClientSession() as session:—— 每次都新建 session，等于每次建新池 - 必须确保整个生命周期只用一个
ClientSession实例，并在所有请求结束后调用await session.close() - 显式配置连接池：传入
connector=aiohttp.TCPConnector(limit=100, limit_per_host=30)，避免单域名打爆连接数
aiohttp 和 requests.Session 在 fd 管理上有什么关键区别？
requests.Session 是同步阻塞模型，连接复用靠 urllib3 的 HTTPAdapter 显式控制；aiohttp 是异步非阻塞，底层用 TCPConnector 管理 socket，但它的“复用”依赖事件循环调度和连接池策略，不是自动生效的。
-
requests.Session的pool_maxsize控制最大空闲连接数，超了就复用或丢弃 -
aiohttp.TCPConnector的limit是全局并发连接总数上限，limit_per_host是单域名上限，两者必须都设，否则容易被某个接口拖垮整池 - aiohttp 不会自动回收 idle 连接，需配合
keepalive_timeout=30主动断连释放 fd
怎么确认真是 fd 耗尽，而不是其他错误伪装成 Too many open files？
先别改代码，直接查系统态。很多报错看着像 fd 耗尽，其实是 DNS 失败、SSL 版本不匹配或代理认证失败，最终 fallback 到 errno 24。
- 运行
lsof -p $(pgrep -f your_script.py) | wc -l，对比输出数字和ulimit -n返回值 - 如果接近或等于
ulimit -n，才是真耗尽；如果才几百，大概率是异常未捕获导致连接没 close，或代理返回 407 后 aiohttp 反复重试建新连接 - 加日志：在
session.get()前后打印len(session.connector._conns)（需 access 私有属性，仅调试用），看连接数是否线性增长
最易被忽略的一点：即使你配了 connector 限流，如果用了 asyncio.create_task() 启动成百上千个协程去发请求，而没用 asyncio.Semaphore 或 asyncio.Queue 控制并发节奏，事件循环会在瞬间把连接池打满——限流参数只是“允许最多开多少”，不是“帮你排队”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
