OSError通常源于系统资源耗尽，尤以文件句柄耗尽为最常见原因；需先查ulimit -n确认软限制，再调高软硬限制并持久化配置，同时配合Python连接池限流与资源清理。
OSError 通常不是并发库本身的错，而是系统资源耗尽的信号——特别是文件句柄（file descriptor）用光了。 Python 的 requests、aiohttp、urllib 等底层都依赖操作系统分配 socket 和临时文件句柄；并发量一高，OSError: [Errno 24] Too many open files 或 [Errno 22] Invalid argument（尤其在重用连接或设置超时参数异常时）就会冒出来。先调系统限制，再调代码逻辑，顺序不能反。
查当前系统文件句柄限制是多少
不查清楚就改，容易白忙活。Linux/macOS 下直接运行：
ulimit -n
这个值是当前 shell 会话的软限制，一般默认是 1024。但实际能用多少，还受硬限制和系统级配置约束。继续查：
ulimit -Hn # 硬限制<br>cat /proc/sys/fs/file-max # 全局最大可分配句柄数
如果 ulimit -n 返回 1024，而你启动了 2000 个并发请求，失败就是必然的——每个连接至少占 1~2 个句柄（socket + 可能的 DNS 缓存 fd），还没算日志、临时文件等。
立即学习“Python免费学习笔记（深入）”；
临时提高 ulimit 值（开发/调试用）
仅对当前终端生效，适合快速验证是否是句柄不足导致的 OSError：
- 先提硬限制（需要 root）：
sudo ulimit -Hn 65536 - 再提软限制：
ulimit -Sn 65536 - 然后运行你的 Python 脚本，比如
python main.py
注意：该设置不会影响已启动的进程，只对后续在该 shell 中启动的进程有效；且重启终端就失效。
永久修改 Linux 文件句柄限制
要让 Python 服务（如用 systemd 启动的爬虫或 API 网关）稳定跑高并发，必须持久化配置：
- 编辑
/etc/security/limits.conf，追加两行（替换your_user为实际用户名）：your_user soft nofile 65536your_user hard nofile 65536 - 确保
pam_limits.so已启用：检查/etc/pam.d/common-session是否含session required pam_limits.so - 如果是 systemd 服务（比如用
systemctl start myapp启动），还需在 service 文件里显式设置：[Service]LimitNOFILE=65536
改完需重新登录用户或重启 systemd 服务才生效。别漏掉最后一步，很多人卡在这儿。
Python 侧配合优化：别光靠堆句柄
系统限制放宽只是基础，代码不收敛连接，照样崩：
- 用
requests.Session()复用连接，禁用Connection: close，避免每请求新建 socket - aiohttp 中务必用
ClientSession配合connector=TCPConnector(limit=100, limit_per_host=30)控制并发连接池大小 - 避免无节制
asyncio.create_task()，用asyncio.Semaphore(50)限流 - 检查是否有未关闭的响应体：
resp.close()或用async with session.get(...)自动清理 - Windows 用户注意：
ulimit不生效，得改注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems里的Windows字符串值，把-c 1024改成-c 65536（风险较高，建议优先换 WSL）
最常被忽略的一点：OSError [Errno 22] 在高并发下有时不是路径问题，而是 socket 超时参数传了负数或 nan，比如误把 timeout=-1 传给 socket.settimeout() —— 这种错不会报明确提示，只在外层抛 Invalid argument，得结合 strace 或 lsof 看系统调用入参。
