用contextlib.ExitStack优雅管理动态数量的资源上下文

Python的with语句只能静态嵌套，但工程中常遇到「资源数量在运行时才确定」的场景：批量打开文件、动态加锁、事务里串联多个子系统。contextlib.ExitStack就是为这种动态上下文管理而生，它把一串上下文管理器压成一个栈，退出时按LIFO自动逆序释放，任一环节抛异常也能保证已获取的资源被正确清理。

一、为什么 with 嵌套不够用

with嵌套要求编译期就知道层数，写成with open(a) as fa, open(b) as fb是固定的。一旦资源来自循环、配置文件或用户输入，就没法用静态嵌套表达。手写try-finally逐个close既冗长又容易漏掉异常分支，尤其在「前N个成功、第N+1个失败需要回滚前N个」的语义下极易出错。ExitStack把这套样板代码收敛进标准库。

二、基础用法：enter_context 逐个压栈

from contextlib import ExitStack

files = ['a.txt', 'b.txt', 'c.txt']
with ExitStack() as stack:
    handles = [stack.enter_context(open(f)) for f in files]
    for fh in handles:
        process(fh)
# 退出时自动按 c->b->a 逆序 close，即使 process 抛异常也安全

enter_context返回原上下文管理器的__enter__结果，并把该管理器登记到栈上。with块正常结束或抛异常，ExitStack.__exit__都会逆序调用每个登记项的__exit__，异常会被层层传递但不会中断清理。

三、register：登记任意回调

不一定是上下文管理器，任何「退出时要执行的清理函数」都能用callback注册。这等价于一个轻量finally，常用于「成功路径才提交、失败回滚」的事务编排。

with ExitStack() as stack:
    conn = acquire_conn()
    stack.callback(conn.rollback)   # 默认兜底回滚
    do_work(conn)
    conn.commit()
    stack.pop_all().close()         # 全部成功，弹出并丢弃回调，不再回滚

pop_all()返回一个新ExitStack接管当前所有登记项并从原栈摘除，对它close即手动触发清理；不close则回调被丢弃。这是「成功提交、失败回滚」的惯用写法。

四、push：登记带参数的清理

push(cm)把一个已实例化的上下文管理器压栈（调用其__exit__而非__enter__），适合「资源已手动获取、只需保证释放」的场景。与enter_context的区别：enter_context会先__enter__再登记__exit__；push只登记__exit__，常配合contextlib.closing包装裸对象。

from contextlib import closing
raw = ThirdPartyClient()
with ExitStack() as stack:
    stack.enter_context(closing(raw))  # 保证 raw.close() 被调用
    raw.connect()

五、实战：批量打开文件 + 首行校验

需求：打开一批日志文件，任一不存在或首行不是合法header就整体回滚（已打开的句柄全部关闭），全部合法才返回句柄列表。用ExitStack写出来既短又正确。

from contextlib import ExitStack

def open_logs(paths):
    with ExitStack() as stack:
        handles = []
        for p in paths:
            fh = stack.enter_context(open(p, encoding='utf-8'))
            first = fh.readline()
            if not first.startswith('# log'):
                raise ValueError(f'{p} bad header')
            handles.append(fh)
        return stack.pop_all(), handles

ctx, handles = open_logs(paths)
with ctx:
    for fh in handles:
        analyze(fh)

关键点：函数内部用ExitStack做「试探性打开」，全部成功后pop_all()把管理权交还给调用方，调用方再with ctx使用。中途任何异常都会让已打开的句柄在栈退出时关闭，不会泄漏。

六、性能与边界

ExitStack内部是个列表，enter_context/register都是O(1)追加，退出时O(n)逆序遍历，开销可忽略。注意三点：一是回调或__exit__本身抛异常会掩盖原始异常（可用suppress或显式记录）；二是pop_all()后原栈变空，再次退出不会再清理已弹出项；三是async场景要用AsyncExitStack，它await协程式的__aexit__，混用同步ExitStack会漏释放。

七、小结

ExitStack把「动态数量的资源 + 异常安全清理」从手写try-finally里解放出来。记住三个原语：enter_context压一个上下文管理器、callback登记裸函数、pop_all移交管理权，足以覆盖批量资源、事务编排、可选依赖串联等绝大多数工程场景。比起层层嵌套with或自己维护资源列表，它更短、更安全、也更易测试。