aiofiles.open() 更常用因其封装异步I/O逻辑、避免线程池开销；而 asyncio.to_thread() 本质仍是同步I/O，大文件下易拖慢事件循环，且Windows退化为线程池，需注意正确用法与平台差异。
async with aiofiles.open() 为什么比 open() + asyncio.to_thread() 更常用
因为 aiofiles.open() 封装了底层文件描述符的异步读写逻辑，避免了线程池调度开销；而 asyncio.to_thread(open) 只是把同步阻塞调用扔进线程池，本质仍是同步 I/O，无法真正释放事件循环。
- 大文件场景下，
to_thread会持续占用一个线程，线程数多时容易拖慢整个 event loop -
aiofiles.open()在 Linux 上依赖io_uring（Python 3.11+）或libuv的异步文件支持，但 Windows 下仍会退化为线程池 —— 这点常被忽略 - 必须配合
async for或await f.read()使用，不能直接调f.readline()（它不是协程）
逐行读大文件时，aiofiles 不支持 async for？
默认不支持。直接写 async for line in f: 会报 TypeError: 'AsyncTextIOWrapper' object is not async iterable。
- 正确做法是用
await f.readline()循环，每次读一行（注意返回含换行符） - 若想用
async for，需手动实现异步迭代器，或改用aiofiles.os.scandir()等更底层接口（不推荐） - 对 GB 级文本文件，建议分块读（如
await f.read(8192)），再用.splitlines()拆解，比逐行更高效
read() 参数设多大才不爆内存又不慢
没有固定值，取决于文件大小、可用内存和下游处理节奏。盲目设 await f.read() 无参数 = 一次性加载全部内容，和同步读没区别，完全失去异步意义。
- 典型安全值：4096–65536 字节（4K–64K），兼顾系统页大小和 Python GC 压力
- 若后续要 JSON 解析，建议按行读或按记录边界读（如每行一个 JSON 对象），避免切在中间导致解析失败
- Windows 上注意
aiofiles默认使用ProactorEventLoop，对大 buffer 读取偶尔有BrokenPipeError，可捕获后重试
为什么 await f.read() 有时卡住不动
常见于文件被其他进程独占写入（如日志轮转中）、NFS 挂载点延迟高、或 aiofiles 版本过低（
立即学习“Python免费学习笔记（深入）”；
- 加超时：用
asyncio.wait_for(f.read(n), timeout=30)防止无限等待 - 检查文件权限和锁：Linux 下用
lsof -p $(pgrep python)看 fd 是否异常堆积 - 升级到
aiofiles>=23.2，旧版在 close() 未完成时重复 read 可能死锁
read() 返回空字节（EOF），但你误判为网络抖动重试，就会无限循环。得靠明确的状态标记和 EOF 检查，而不是只看返回值长度。 
