Python contextlib.AsyncExitStack 如何保证异步资源逆序释放：部分初始化失败的回滚边界

异步服务启动到一半才发现会话鉴权失败，最麻烦的通常不是异常本身，而是前面已经打开的数据库连接、临时会话和文件句柄没有跟着退出。contextlib.AsyncExitStack 的价值正在这里：资源成功拿到后立即登记清理动作，后续任一步抛错，都能由同一个 aclose() 按逆序收尾。

把“获取资源”和“登记清理”放在同一个成功分支里；初始化失败时只要调用一次 aclose()，已经登记的资源就会从最后一个开始依次释放。

启动故障的影响面：资源拿到了，却没有完整退出

假设一个请求处理器需要先打开数据库连接，再创建异步会话，最后加载远端配置。第三步返回 RuntimeError 时，前两步已经完成。如果资源的退出逻辑分散在多个局部变量里，异常路径很容易漏掉其中一个。

这个问题有一个明显信号：服务日志只出现初始化失败，但连接池的活动连接数没有回落，或者下一次测试启动时出现“资源仍被占用”。这里别急着把异常吞掉，先画出成功顺序和失败出口。

触发条件：初始化流程中途失败，清理责任被切断

AsyncExitStack 解决的不是“如何捕获所有异常”，而是把清理责任集中到一个栈里。资源一旦成功进入，就马上登记；如果后面失败，异常会沿着正常的 try/finally 出口走到 aclose()。

from contextlib import AsyncExitStack

async def build_context(open_db, open_session, load_config):
    async with AsyncExitStack() as stack:
        db = await stack.enter_async_context(open_db())
        session = await stack.enter_async_context(open_session())
        config = await load_config()
        return db, session, config

在这段代码里，db 和 session 成功进入后已经登记退出动作。load_config() 抛出 RuntimeError 时，async with 仍然会调用栈的关闭逻辑，两个资源按登记顺序的反方向退出。

根因拆开看：资源登记顺序就是回滚顺序

如果资源 A 依赖资源 B，通常应该先登记 B，再登记 A。这样关闭时 A 先退出，B 后退出，依赖关系不会被提前拆掉。enter_async_context 用于异步上下文管理器；若资源只提供一个异步关闭函数，可以用 push_async_callback 补上清理动作。

from contextlib import AsyncExitStack

async def prepare(open_db, make_session, close_session):
    async with AsyncExitStack() as stack:
        db = await stack.enter_async_context(open_db())

        session = await make_session(db)
        stack.push_async_callback(close_session, session)

        return db, session

这里的关键不是变量名，而是时机：make_session(db) 成功返回后才调用 push_async_callback。如果创建失败，就没有一个半成品会被误清理；如果后续步骤失败，aclose 会先执行 close_session，再退出 db，最终状态就是“资源已释放”。

修复动作：把失败出口收敛到一个可验证的清理点

当初始化函数需要返回资源给调用方时，可以把栈交给调用方管理；更常见的做法是让栈包住完整的业务作用域。不要在资源刚创建前就登记一个依赖该资源的清理回调，也不要在清理函数里再次修改主流程状态。

async def run_job(open_db, make_session, close_session, load_config):
    async with AsyncExitStack() as stack:
        db = await stack.enter_async_context(open_db())
        session = await make_session(db)
        stack.push_async_callback(close_session, session)
        config = await load_config()
        return await do_work(db, session, config)

验收时至少模拟三条路径：open_db 失败、make_session 失败、load_config 失败。前两条不应调用尚未登记的清理动作，第三条必须看到 session 先关闭、db 后退出。成功路径则由 async with 在任务完成后统一收尾。

防复发检查：清理动作也要有自己的失败策略

aclose() 不是魔法保险箱。清理回调本身如果抛错，可能影响后续退出动作的可观测性，所以生产代码要给清理函数写日志，并明确哪些异常可以记录后继续、哪些异常必须让任务失败。

另一个容易忽略的边界是重复关闭。把 AsyncExitStack 的生命周期限定在一个明确作用域内，避免一处显式调用 aclose()、另一处又依赖外层 async with 关闭同一批资源。若业务确实需要手动提前释放，就把它当成状态转换测试，而不是默认写法。

相关问题：AsyncExitStack 的边界怎么判断

普通同步上下文管理器能直接放进 AsyncExitStack 吗

不能把同步资源当成异步资源直接交给 enter_async_context。同步资源应使用同步的 ExitStack，或明确使用对应的异步适配层。

什么时候用 push_async_callback

当资源没有异步上下文管理器协议，但你有一个明确的异步清理函数时使用。回调参数要在资源成功创建后登记。

aclose 调用一次后还能继续登记资源吗

不要把已关闭的栈当作可复用容器。把它视为已经完成生命周期的对象，新的资源使用新的 AsyncExitStack 管理。

如何确认释放顺序真的符合预期

给 close_session 和数据库上下文的退出方法写测试日志，分别覆盖成功、初始化中途抛出 RuntimeError 和清理回调异常三种路径，检查事件序列而不是只断言最终返回值。

最后的判断规则

只要一个异步初始化流程存在“前面成功、后面可能失败”的窗口，就应在每次成功拿到资源后立即登记清理。enter_async_context 负责协议完整的异步资源，push_async_callback 负责补充异步关闭函数，aclose 负责在一个明确出口执行逆序回滚。把这三件事的责任分开，故障路径就能和成功路径一样被测试。