AsyncExitStack 怎样统一清理异步资源

当异步函数里只管理一个连接时，async with 已经足够；但资源数量由配置、用户输入或运行分支决定时，逐层嵌套很快会变得难读。AsyncExitStack 的价值是把这些资源的退出责任集中到一个栈里：异步上下文管理器用 enter_async_context 登记，同步上下文管理器用 enter_context 登记，最后由 aclose 按注册的逆序释放。

官方文档：https://docs.python.org/3/library/contextlib.html

一句话理解：资源在哪里创建并不重要，关键是创建成功后立刻把对应的退出动作登记给同一个 AsyncExitStack。

先确定 AsyncExitStack 负责什么

AsyncExitStack 是 contextlib 提供的异步上下文管理器，适合把多个同步或异步上下文管理器，以及需要等待的清理协程，组合到一处。它并不替你创建数据库连接或 HTTP 会话，也不会替你判断资源是否应该长期持有；它主要负责保存退出回调，并在退出时统一调用。

它有两个容易混淆的边界。第一，异步资源要用 enter_async_context，这个方法需要等待异步进入；同步文件等普通上下文管理器则用 enter_context。第二，异步栈没有可直接替代的 close，完整释放要调用 aclose，因为其中可能包含需要等待的清理逻辑。

把异步资源登记到同一个栈

常见写法是让资源装配函数本身进入 async with AsyncExitStack()，每成功拿到一个资源，就立即登记它的退出责任。这样即使后面的资源创建失败，已经成功创建的前置资源也会被栈清理。

from contextlib import AsyncExitStack

async def build_resources(db_manager, http_session, file_path):
    # 一个栈统一保存本次装配过程中已经成功取得的资源
    async with AsyncExitStack() as stack:
        # 异步上下文管理器需要 await 进入，并由栈负责退出
        db = await stack.enter_async_context(db_manager.connect())
        session = await stack.enter_async_context(http_session())

        # 普通同步上下文管理器直接登记，不要对 enter_context 使用 await
        log_file = stack.enter_context(open(file_path, "a", encoding="utf-8"))
        return db, session, log_file

这个示例的重点不是三个资源的具体类型，而是登记时机：connect() 或 http_session() 成功后，退出方法已经进入栈；打开同步文件后也立即登记。函数离开 async with 时，资源会按后进先出的顺序退出。

如果第二个异步资源进入失败，第一个数据库连接仍然会被释放；如果同步文件打开失败，前面两个异步资源也仍然会走退出路径。这正是动态资源场景比多层 async with 更适合退出栈的地方。

补上没有上下文管理器的清理函数

有些库只给出 close()、aclose() 或自定义释放函数，并没有标准的上下文管理器。此时可以用 push_async_callback 登记异步清理协程，用 push 登记符合退出回调签名的同步清理函数。注册函数本身不会马上清理资源，清理发生在栈退出时。

from contextlib import AsyncExitStack

async def open_with_callbacks(make_client, make_cache):
    async with AsyncExitStack() as stack:
        # 手动创建后立刻登记异步释放，避免异常路径遗漏
        client = await make_client()
        stack.push_async_callback(client.aclose)

        # 同步清理函数可用 push 登记，函数签名要能接收退出信息
        cache = make_cache()
        stack.push(lambda exc_type, exc, tb: cache.close() or False)

        return client, cache

push_async_callback 适合只需要等待一个协程函数的情况；它不会把异常详情传给回调。push 更接近上下文管理器的退出协议，回调可以根据异常参数决定是否抑制异常，但业务代码通常应该返回假值，让原始异常继续向外传播。

如果资源已经完成交接，不应让原栈继续负责释放，可以用 pop_all() 把已登记的退出回调转移到新的栈，再由新的所有者决定何时调用 aclose。这适合“初始化成功后把资源交给更长生命周期对象”的场景，但交接动作必须和所有权变化放在一起，否则容易出现重复释放或无人释放。

用最小规则确认退出顺序

把使用边界压缩成三条规则，基本就能覆盖大多数 AsyncExitStack 场景：

• 能用异步上下文管理器表达的资源，用 await stack.enter_async_context(...)。
• 普通同步上下文管理器用 stack.enter_context(...)；只有清理协程时，用 push_async_callback。
• 资源创建成功后马上登记；需要移交所有权时才考虑 pop_all()，显式关闭栈时使用 await stack.aclose()。

因此，AsyncExitStack 的核心不是“把所有关闭方法都塞进去”，而是建立清晰的资源所有权：谁创建、谁登记、谁最终关闭。只要登记动作紧跟资源创建，后续异常通常不会留下半初始化状态。

相关问题

AsyncExitStack 可以只管理同步文件吗？

可以。同步文件通过 enter_context 登记即可；只要外层是 async with，退出时仍由异步栈统一处理。

为什么不能对 AsyncExitStack 调用 close？

因为异步栈的退出回调可能需要等待，官方接口提供的是 aclose。在异步上下文中，让 async with 自动退出通常更不容易漏掉等待。

什么时候不需要 AsyncExitStack？

资源数量固定、嵌套关系简单时，直接写清晰的 async with 往往更直观；退出栈主要解决动态数量、可选资源和混合同步/异步清理的问题。