Python contextlib.AsyncExitStack 如何清理异步资源

异步代码里如果资源数量由配置或运行结果决定，连续写多个 async with 很快就会变得笨重。contextlib.AsyncExitStack 的解决办法是把资源的退出动作集中登记：支持异步上下文管理器时用 enter_async_context，只有异步清理函数时用 push_async_callback，最后由 async with 自动触发清理。需要手动收尾时调用的是 await stack.aclose()，不是同步的 close()。

一句话判断：资源数量不固定、获取过程可能中途失败，或同一段任务同时混合多种异步清理动作时，优先让 AsyncExitStack 统一托管；正常离开作用域会按后注册先清理。

官方说明：AsyncExitStack 位于 Python 标准库 contextlib，文档地址是 https://docs.python.org/3/library/contextlib.html。下面的示例只展示资源管理关系，示例中的连接对象是自定义的异步上下文管理器。

先把资源归拢到一个异步栈

先看最常用的组合：一个资源实现了 __aenter__/__aexit__，另一个资源只提供异步关闭函数。两者可以放进同一个栈，但注册方式不同。enter_async_context 会等待资源进入并返回进入结果；push_async_callback 则不会替你获取资源，只登记将来要等待的清理协程。

from contextlib import AsyncExitStack

async def load_resources(resource_factory, session):
    # async with 离开时会自动调用栈中的异步退出动作
    async with AsyncExitStack() as stack:
        connection = await stack.enter_async_context(
            resource_factory.connection()
        )
        # 只登记异步清理，不把协程函数误传给同步 callback
        stack.push_async_callback(session.aclose)
        return connection, session

这里有一个容易忽略的边界：push_async_callback 接收的是协程函数和参数，而不是已经执行过的协程对象。资源已经打开后再登记清理，才能保证后续获取失败时，前面已经登记的动作仍在栈里。

中途失败时，逆序清理才是关键

批量打开资源时，失败点可能出现在第二个或第三个资源。把每个资源分别写在不同的 try/finally 中，不仅层级深，还容易漏掉某个分支。栈的价值在于：成功注册的动作一直留在同一处，后续获取抛出异常时，已登记动作仍会被清理。

async def open_many(factories):
    async with AsyncExitStack() as stack:
        resources = []
        for factory in factories:
            # 每成功进入一个资源，就立刻加入退出栈
            resource = await stack.enter_async_context(factory())
            resources.append(resource)
        return resources

清理顺序与注册顺序相反，类似嵌套的 async with。因此依赖关系应从外到内注册：先注册共享连接，再注册依赖该连接的事务或流。这样后注册的事务先结束，底层连接最后释放。

如果不能把栈写成 async with，就显式放进 try/finally，并等待 aclose()：

async def manual_lifecycle(factory):
    stack = AsyncExitStack()
    try:
        # 手动模式也要在资源成功获取后马上登记
        resource = await stack.enter_async_context(factory())
        return resource
    finally:
        # AsyncExitStack 的收尾必须等待异步退出动作
        await stack.aclose()

几种写法怎么选，边界在哪里

不要为了“统一”而把所有对象都塞进异步栈：单个资源且生命周期清楚时，直接写 async with 更容易读。栈适合动态数量、可选资源和多种清理方式混合的场景。还要避免重复使用同一个栈嵌套管理不同生命周期，否则内层退出可能提前清空外层登记的回调。

常见问题

AsyncExitStack 为什么不能调用 close？

它需要正确等待异步退出动作，所以标准接口是协程方法 aclose()。手动管理时必须写 await stack.aclose()。

enter_async_context 和 push_async_callback 有什么区别？

前者负责进入一个异步上下文管理器并登记退出方法；后者只登记一个异步清理回调，资源的获取由你自己完成。

获取资源失败后，之前的资源会释放吗？

只要之前的资源已经成功登记在栈中，离开 async with 时就会执行对应清理；尚未成功获取的资源不会凭空产生清理回调。

为什么清理回调要尽早注册？

因为注册动作就是栈的责任边界。先获取、后做大量业务、最后才登记，会让中途异常留下没有保护的资源。

落地前的检查清单

• 异步上下文管理器走 enter_async_context，异步关闭函数走 push_async_callback。
• 资源成功获取后立即注册，不把清理动作拖到业务逻辑末尾。
• 确认清理顺序满足依赖关系，并为取消与异常保留同一条收尾路径。
• 脱离 async with 时使用 await aclose()，不要写成 close()。