直接用open()在asyncio中会阻塞，因其是同步系统调用，无法让出控制权，导致事件循环挂起、其他协程无法调度；aiofiles通过线程池封装实现异步文件操作，避免阻塞。
为什么直接用 open() 在 asyncio 里会阻塞？
asyncio 事件循环无法在 open()、read()、write() 这类系统调用上自动挂起，因为它们是同步的底层 I/O 操作。哪怕你把它包在 async def 里，也会卡住整个 event loop，导致其他协程无法调度。
常见错误现象：RuntimeWarning: coroutine 'open' was never awaited（误以为返回的是协程），或者程序“假死”——比如一个 HTTP 请求要等文件读完才响应。
真正能释放控制权的，是把阻塞操作扔进线程池（如 loop.run_in_executor()），而 aiofiles 就是帮你封装好这层的库。
安装与基础写法：别漏掉 await 和 async with
aiofiles 不是 Python 标准库，需单独安装：
立即学习“Python免费学习笔记（深入）”；
pip install aiofiles
它模仿内置 open() 的接口，但所有 I/O 方法都返回协程，必须 await：
-
aiofiles.open()返回一个异步上下文管理器，不能直接open(...).read() - 必须用
async with，否则资源不释放、句柄泄漏 -
.read()、.write()、.readline()都要await
示例（安全读取）：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
import aiofiles
<p>async def read_config():
async with aiofiles.open("config.json", mode="r") as f:
content = await f.read() # ← 必须 await
return content
aiofiles 的模式和缓冲区参数怎么选？
mode 和内置 open() 一致，但注意：
- 二进制模式（
"rb"/"wb"）更安全，避免编码/解码开销；文本模式默认用locale.getpreferredencoding()，可能出错 -
buffering=0在文本模式下被忽略（Python 规定）；二进制模式下设为0表示无缓冲，但会禁用readline() - 不支持
newline参数（文本换行处理需手动）
性能影响：大文件读取时，建议用 await f.read(8192) 分块，而非 await f.read() 一次性加载——后者会把整个文件塞进内存，且仍是阻塞式等待磁盘 I/O 完成（只是不阻塞 event loop）。
并发读多个文件时，为什么顺序执行反而更快？
aiofiles 本身不提供并行磁盘 I/O；它只是把每个文件操作交由线程池异步执行。而机械硬盘（HDD）或某些 SSD 在随机小 I/O 下，并发读多个文件会导致磁头/队列争抢，实际耗时可能高于串行。
使用场景判断：
- 适合：I/O + CPU 混合任务（如读文件 → 解析 JSON → 调 API），让解析和网络请求与其他文件读取重叠
- 不适合：纯顺序读大文件，或大量小文件集中在同一目录下（OS 层面的磁盘调度瓶颈）
- 若真需高吞吐，考虑
concurrent.futures.ProcessPoolExecutor或 mmap
容易踩的坑：asyncio.gather(*[aiofiles.open(...) for _ in range(10)]) 会瞬间创建 10 个线程去争抢文件句柄，可能触发 OSError: [Errno 24] Too many open files。应限制并发数，或改用 asyncio.Semaphore。
磁盘 I/O 的非阻塞本质，是把“等数据从磁盘搬进内存”这个动作移出 event loop，而不是让它变快。这点常被忽略。
