Python多线程上传文件效果差，根本原因是GIL虽不制约I/O，但默认阻塞式HTTP请求导致线程卡在connect/recv上，引发超时、重置、内存暴涨和重复DNS查询；正确做法是用ThreadPoolExecutor配合Session连接池、合理超时与域名预解析。
Python 3.11 中用 threading 提高文件上传速度，效果非常有限，甚至可能更慢——因为 GIL 会严重制约 CPU 密集型任务，而文件上传本质是 I/O 密集型，但实际瓶颈常在 socket 阻塞、连接复用、服务端限速或 DNS 解析上，不是靠开更多线程就能突破的。
为什么 threading 在上传场景下容易失效
Python 的 threading 模块无法绕过 GIL，但上传本身不耗 CPU；真正卡住的是阻塞 I/O（比如 requests.post() 等待响应）。默认 HTTP 连接是阻塞 + 无连接池复用的，大量线程会挤在 connect() 或 recv() 上，反而引发：
-
TimeoutError: [Errno 110] Connection timed out（端口耗尽或服务端拒绝） - 大量
ConnectionResetError（服务端主动断连） - 内存暴涨（每个线程维持独立 socket 和 SSL 上下文）
- DNS 查询被重复触发（未复用
Resolver或缓存）
改用 concurrent.futures.ThreadPoolExecutor + 连接池才是正解
比起裸写 threading.Thread，ThreadPoolExecutor 能控并发数、统一异常处理、避免线程无限创建。但关键在配合 requests.Session 复用连接：
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 每个线程应复用同一个
Session实例（注意：不能跨线程共享 Session，需在线程内创建或使用threading.local） -
Session必须设置mount自定义适配器，如HTTPAdapter(pool_connections=10, pool_maxsize=20) - 超时必须显式设为
timeout=(3.0, 10.0)（连接+读取分离），避免单个卡死拖垮整池 - 示例核心逻辑：
def upload_file(filepath): session = requests.Session() adapter = requests.adapters.HTTPAdapter( pool_connections=10, pool_maxsize=20, max_retries=2 ) session.mount('https://', adapter) with open(filepath, 'rb') as f: r = session.post( 'https://api.example.com/upload', files={'file': f}, timeout=(3.0, 10.0) ) return r.status_code
真正提速的关键不在“线程数”，而在减少 I/O 等待
线程数设为 min(32, os.cpu_count() * 5) 是常见误区——上传不是算力问题。实测有效策略是：
立即学习“Python免费学习笔记（深入）”；
- 把线程数压到
4–8，重点优化单次请求：启用gzip压缩（服务端支持前提下）、去掉冗余 headers - 预解析域名：用
socket.gethostbyname('api.example.com')+requests.adapters.HTTPAdapter的pool_block=False避免每次 DNS 查询 - 小文件（multipart/form-data 合并上传（需服务端支持），减少请求数
- 大文件务必分片 + 断点续传（如用
Content-Range），否则单次超时概率指数上升
最常被忽略的一点：服务端是否对同一 IP 的并发连接做了限制？很多对象存储（如 MinIO、阿里云 OSS）默认只允许每 IP 10–20 个并发 TCP 连接，盲目加线程只会触发限流，返回 429 Too Many Requests 或直接 RST。先查服务端文档，再调客户端参数。
