aiofiles 不加速磁盘 I/O，仅避免阻塞事件循环；它通过线程池封装同步文件操作，适用场景为多任务并发且 I/O 等待是瓶颈时，而非单纯追求写入速度。
aiofiles 确实能让你的文件写入“看起来”异步，但它本身不加速磁盘 I/O，反而可能更慢——除非你明确知道为什么、在什么场景下用它。
aiofiles.open 本质是线程池封装，不是真异步 I/O
- Python 标准库的
open()是同步阻塞调用，会卡住事件循环 -
aiofiles并没有绕过操作系统限制，而是用loop.run_in_executor()把open()、write()等操作扔进默认线程池（concurrent.futures.ThreadPoolExecutor） - 所以它解决的是「不阻塞事件循环」的问题，不是「写得更快」的问题
常见误用现象：
- 用
aiofiles.open(..., 'w')逐行写入 1000 个小文件，总耗时比同步还长 - 没调大线程池，默认只有
min(32, os.cpu_count() + 4)个线程，大量并发写入时排队严重
正确做法：
-
import aiofiles前先配置自定义线程池：import asyncio from concurrent.futures import ThreadPoolExecutor import aiofiles </li></ul><h1>创建更大线程池（例如 16 线程）</h1><p>executor = ThreadPoolExecutor(max_workers=16) loop = asyncio.get_running_loop() loop.set_default_executor(executor)</p><p>async def write_one(filename, data): async with aiofiles.open(filename, 'w') as f: await f.write(data)
- 单次写入量尽量大，避免高频小写：攒够 8KB+ 再
await f.write(buffer)，而不是每行都await
异步写入真正提速的前提：I/O 不是瓶颈，等待才是
aiofiles只在以下场景带来实际收益：立即学习“Python免费学习笔记（深入）”；
- 你同时做很多事：比如一边发 HTTP 请求、一边解析 JSON、一边写日志 —— 这时用
aiofiles避免写文件拖垮整个协程流 - 文件目标是网络文件系统（如 NFS、S3FS）或高延迟存储（某些云盘），同步写会卡几百毫秒，而线程池能并行消化这些等待
- 你已经在用
asyncio.gather()并发调度几十个写任务，且磁盘带宽没打满（SSD 随机写通常 >50K IOPS）
反例（别这么干）：
- 把一个 2GB CSV 拆成 200 万行，每行起一个
aiofiles.open协程 → 线程池过载 + 文件句柄爆炸 + 磁盘寻道雪崩 - 在单核 VM 或低配云服务器上开 100 个
aiofiles写任务 → CPU 调度开销压倒 I/O 收益
替代方案往往比
aiofiles更有效如果你的目标是「写得更快」，优先考虑这些：
- 批量写入：用
file.write()一次性写入大字符串/字节块，而非分多次await f.write() - 换格式：写
.parquet或.feather比写 CSV 快 3–10 倍，Pandas 的to_parquet()默认就带缓冲和压缩 - 绕过 Python：用
subprocess调dd、cat或pv，尤其适合管道场景 - 真异步 I/O（Linux）：用
io_uring绑定的库（如anyio未来可能支持），但目前 Python 生态还不成熟
aiofiles的价值不在速度，而在调度自由度——它让你能把文件操作和其他异步任务放在同一个事件循环里协调。但一旦你开始盯着「写入耗时」优化，就得立刻跳出协程层，去看磁盘队列深度、缓冲区大小、文件系统挂载参数这些真实瓶颈。 - 单次写入量尽量大，避免高频小写：攒够 8KB+ 再
