threading比multiprocessing更适合IO密集型任务，因GIL不阻塞系统调用，IO等待时线程让出CPU，其他线程可继续执行；而multiprocessing启动开销大、通信成本高，属过度设计。
为什么 threading 比 multiprocessing 更适合 IO 密集型任务
因为 Python 的 GIL 不会阻塞系统调用（如网络请求、磁盘读写），IO 等待期间线程会主动让出 CPU，此时其他线程可继续执行。而 multiprocessing 启动开销大、进程间通信成本高，对纯 IO 场景是过度设计。
- 典型场景：
requests.get()批量调用、open()读取多个小文件、数据库fetch()查询 - 注意：若任务中混有 CPU 计算（比如解析 JSON 后做统计），需拆分——IO 部分用线程，计算部分考虑
concurrent.futures.ProcessPoolExecutor - 默认线程数不宜设得过高（如 100+），容易触发系统级连接数限制或服务端限流；建议从 10–30 开始压测
用 asyncio + aiohttp 替代同步 requests 的关键点
异步不是“自动变快”，而是避免线程空等。但必须所有 IO 调用都异步化，否则一个 time.sleep(1) 或 requests.get() 就会让整个 event loop 卡住。
- 不能混用同步库：把
requests放进asyncio.to_thread()是兜底方案，但失去异步优势 -
aiohttp.ClientSession必须复用，每次新建 session 会重建连接池，抵消并发收益 - 错误处理要显式：HTTP 异常（如
aiohttp.ClientError）、超时（asyncio.TimeoutError）不会被try/except Exception捕获全
async with aiohttp.ClientSession() as session:
tasks = [fetch_url(session, url) for url in urls]
results = await asyncio.gather(*tasks, return_exceptions=True)
文件读写频繁时，别忽略操作系统缓存和缓冲区设置
Python 默认的 open() 使用系统页缓存，但小文件高频读写仍可能成为瓶颈。盲目加线程不一定提升吞吐，反而因上下文切换拖慢整体速度。
- 批量读：优先用
os.listdir()+pathlib.Path.read_text()，比循环open()更简洁；大文件用io.BufferedReader控制buffering参数 - 批量写：避免逐行
f.write()，改用'\n'.join(lines)一次性写入；日志类场景可用logging.handlers.RotatingFileHandler内置缓冲 - 注意：NFS 或网络存储上，
os.stat()可能比读文件本身还慢，缓存元信息比反复 stat 更有效
concurrent.futures.ThreadPoolExecutor 的 timeout 和 max_workers 容易被误设
这两个参数直接决定任务是否“看似卡死”或“大量失败”。timeout 是单个 submit() 的执行上限，不是整个 map() 的总耗时。
立即学习“Python免费学习笔记（深入）”；
-
max_workers=None在 Python 3.8+ 表示min(32, os.cpu_count() + 4)，对 IO 任务通常偏少，需手动设为 20–50 -
timeout设太短（如 0.5 秒）会导致大量concurrent.futures.TimeoutError，设太长（如 300 秒）会让失败任务拖住后续调度 - 提交任务后，记得调用
as_completed()或result()获取结果，否则异常会被静默吞掉
最常被忽略的是：线程池 shutdown 后不能再 submit，但未完成的任务仍会继续运行——这在长周期脚本里容易引发资源泄漏。
