asyncio.create_task()更适合实时日志采集，因其支持真正并发读取多源日志；直接await会导致串行阻塞，而create_task可批量启动任务并用gather统一等待，配合aiofiles异步文件读、queue缓冲节流及信号清理机制保障稳定性。
为什么 asyncio.create_task() 比直接 await 更适合日志采集
实时日志采集要求多个文件或网络源能并发读取，但不能阻塞主线程——直接 await 单个日志源会串行等待，延迟累积。用 asyncio.create_task() 把每个日志源的读取逻辑包装成独立任务，调度器才能真正并发执行。
常见错误是把所有 await 写在 for 循环里，结果变成“伪异步”；正确做法是先批量创建任务，再统一 await asyncio.gather(*tasks) 等待全部完成。
- 每个日志源（如
/var/log/nginx/access.log）应封装为一个async def tail_file(path: str)协程 - 避免在任务内部调用
time.sleep()，改用await asyncio.sleep(0.1) - 如果某日志源临时不可读（如权限拒绝），任务应捕获
PermissionError并记录警告，而不是崩溃整个采集流程
如何用 aiofiles 避免阻塞式文件读取
aiofiles 是 asyncio 生态中少数可靠支持异步文件 I/O 的库，但它不支持 tail -f 这类实时追加读取——它只提供异步的 open/read/write，不自带轮询或 inotify 机制。
所以实际采集时得自己实现“非阻塞轮询”：每次 await f.seek(0, 2) 获取当前文件末尾位置，再 await f.read()，然后对比偏移量变化。注意 aiofiles 的 mode 必须含 'b'（如 'rb'）才能正确处理二进制偏移，否则中文日志可能解码失败。
- 不要用
aiofiles.open(..., mode='r')直接读文本——编码问题会导致UnicodeDecodeError - 推荐先以
'rb'模式读取，再用line.decode('utf-8', errors='ignore')安全解码 - 频繁
seek()+read()会产生大量小 I/O，建议每 100ms 检查一次，而非 1ms
怎样让 asyncio 事件循环稳定运行而不被日志爆炸拖垮
生产环境日志写入频率可能高达每秒数千行，如果每行都触发一次 print() 或网络发送，事件循环会迅速堆积未完成的协程，最终内存溢出或响应延迟飙升。
关键对策是引入缓冲与节流：用 asyncio.Queue 做中间队列，采集协程只负责往里 put 行数据；另起一个消费者任务，批量取（比如每次取 50 行）再统一处理。这样既避免高频调度开销，又能控制下游压力。
- 设置
asyncio.Queue(maxsize=1000)防止内存无限增长，满时采集协程应await queue.join()等待消费 - 消费者任务里别用
while True:无休止循环，要加await asyncio.sleep(0.01)让出控制权 - 若下游是 HTTP 上报，务必对
aiohttp.ClientSession复用，且限制并发连接数（connector = aiohttp.TCPConnector(limit=5)）
遇到 RuntimeError: Event loop is closed 怎么办
这个错误通常出现在程序退出时，采集任务还在运行、试图访问已关闭的事件循环。根本原因不是代码写错，而是没做干净的资源清理。
必须显式调用 asyncio.run() 启动主协程，并在主协程结尾用 asyncio.shield() 包裹 cleanup 逻辑；更稳妥的做法是监听 SIGINT 和 SIGTERM，在信号处理器里取消所有任务并等待它们结束。
- 不要在
finally块里直接调用loop.close()——asyncio.run()已自动处理 - 采集任务中若用了
async with aiohttp.ClientSession() as session:，确保 session 生命周期被正确包裹在任务内 - 调试时可用
asyncio.all_tasks()查看残留任务，定位哪个协程没被 cancel
日志采集真正的难点不在“怎么异步”，而在“怎么稳住异步”——偏移跟踪不准、编码异常、队列背压、信号处理遗漏，任何一个点没兜住，系统就从实时变成间歇性丢日志。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
