asyncio.Task 忘记 cancel 会导致内存泄漏，因悬停任务持续持有协程帧和变量引用；async with/for 异常跳出、滥用 __del__/weakref、忽略第三方库私有缓冲区等亦是常见原因。
asyncio.create_task() 后忘记 cancel() 导致任务悬停
未取消的 asyncio.Task 会持续持有协程帧、局部变量和闭包引用，哪怕协程已退出或 await 的对象早已销毁。典型现象是：程序空闲时 RSS 内存缓慢上涨，psutil.Process().memory_info().rss 持续增长，且 asyncio.all_tasks() 返回大量状态为 Pending 或 Running 的任务。
- 用
asyncio.create_task()启动任务后，必须确保它有明确的生命周期管理——比如在__aexit__、finally块或信号处理中调用task.cancel() - 避免在循环里无节制地
create_task()而不加限流或等待完成，例如：for url in urls: asyncio.create_task(fetch(url))应改为await asyncio.gather(*[fetch(u) for u in urls])或配合asyncio.Semaphore -
task.cancel()不等于立即释放内存；需后续await task（或忽略CancelledError）让协程真正退出帧栈，否则任务仍卡在Cancelled状态并持引用
async with / async for 中异常跳出导致上下文未退出
异步上下文管理器（如 aiohttp.ClientSession、aiomysql.Pool）或异步迭代器（如 aiosqlite.Cursor）若在 async with 块内抛出未捕获异常，__aexit__ 可能不执行，底层连接/缓冲区/临时对象无法释放，形成间接内存泄漏。
- 所有
async with块都应包裹在try/except中，或确保异常被上层捕获并允许正常退出上下文 - 不要在
async for循环中用break或return跳出而不先aclose()迭代器（部分库支持，但非通用）；更稳妥的做法是用asyncio.shield()包裹关键清理逻辑 - 检查所用异步库是否实现了完整的
__aexit__清理——比如旧版aiofiles在异常下可能漏关文件句柄，升级到 23.2+ 更可靠
用 weakref 或 __del__ 试图“自动”清理异步资源
在协程对象、Task 或异步类实例上依赖 __del__ 或 weakref.finalize 触发 cancel() / aclose()，大概率失效。因为 asyncio 的事件循环不保证及时回收，且 __del__ 在循环引用存在时根本不会调用。
- 绝不在
__del__中调用await或任何需要事件循环的操作；它运行在任意线程，且无 event loop 上下文 -
weakref.finalize的回调是同步函数，不能直接await，也不能安全调用loop.create_task()（loop 可能已关闭） - 正确做法是显式暴露
close()或shutdown()方法，并由使用者负责调用——比如 FastAPI 的lifespan事件、Starlette 的on_shutdown
排查时别只看 top，要 inspect 运行中的 Task 和 Refs
内存泄漏不是靠 RSS 数值猜出来的。得进进程内部看谁还活着、谁还被谁拽着。
立即学习“Python免费学习笔记（深入）”；
- 用
asyncio.all_tasks(loop)列出所有存活 Task，过滤掉done()为True的，再对剩余 Task 调用task.get_coro()查看其协程名和当前cr_frame.f_locals，常能发现残留的大型数据结构（如未清空的list缓存、未 close 的BytesIO） - 用
gc.get_referrers(obj)定位谁在引用可疑对象；注意Task本身会被asyncio._ready、_scheduled等内部队列强引用，得结合obj.__class__和type(obj)判断是否属于业务逻辑 - 生产环境慎用
tracemalloc+asyncio，因为tracemalloc.start(25)会影响协程调度性能；建议在复现环境用sys.settrace配合asyncio.current_task()打点关键路径
最麻烦的泄漏往往藏在第三方异步库的私有字段里，比如某个 _buffer 属性被意外保留了 10MB 数据却没文档说明——这时候只能靠 obj.__dict__ 一层层扒，别指望日志或文档提前告诉你。
