Python ExitStack 动态清理：第三个资源打开失败，前两个怎样按倒序释放
资源数量运行时才知道
一个任务要按清单打开多个输入文件，再创建输出通道。清单长短不固定，第三次获取还可能失败。如果先把所有资源放进列表，最后才安排关闭，中途异常可能让前面已经成功打开的资源无人管理。ExitStack 可以在每次成功进入后立即登记退出动作。
下面不访问真实文件，而用带事件记录的资源对象观察生命周期。实验环境为 Python 3.12.14，保存为 demo.py 后运行 python demo.py。例子故意让 C 在进入阶段报错，并另外运行全部成功的路径，检查两种情况下 A、B 是否都按相反顺序退出。
只登记已经成功进入的对象
Resource 的 __enter__ 先记录尝试，再决定是否失败；只有成功时才把自己放进 active 集合。__exit__ 负责移除并记录退出。每次都使用 stack.enter_context(resource)，让进入与登记连在一起。不要先进入一批资源，等所有操作结束后才想起把清理函数加进栈。
fail=True 的 C 在获得资源之前就抛出异常，因此 active 中从未有 C，退出记录也不应包含它。若真实 __enter__ 已经完成了部分获取才失败，该对象必须自行处理那部分清理；外部栈不能替失败的进入过程猜测哪些内部状态需要撤销。
AI概念示意图：后续入口失败时，清理动作沿相反方向返回已成功获取的资源。图片只说明概念，不是运行截图。
from contextlib import ExitStack
events = []
active = set()
class Resource:
def __init__(self, name, fail=False):
self.name = name
self.fail = fail
def __enter__(self):
events.append("enter:" + self.name)
if self.fail:
raise RuntimeError(self.name + " failed")
active.add(self.name)
return self
def __exit__(self, exc_type, exc, tb):
active.remove(self.name)
events.append("exit:" + self.name)
return False
try:
with ExitStack() as stack:
for name in ["A", "B", "C"]:
stack.enter_context(Resource(name, fail=name == "C"))
raise AssertionError("C should fail before this line")
except RuntimeError as exc:
assert str(exc) == "C failed"
assert not active
assert events == ["enter:A", "enter:B", "enter:C", "exit:B", "exit:A"]
print("failure:", events)
events.clear()
with ExitStack() as stack:
resources = [stack.enter_context(Resource(name)) for name in ["A", "B"]]
assert active == {"A", "B"}
assert [r.name for r in resources] == ["A", "B"]
events.append("body")
assert not active
assert events == ["enter:A", "enter:B", "body", "exit:B", "exit:A"]
print("success:", events)用事件顺序证明清理确实发生
failure 一行依次显示 enter:A、enter:B、enter:C、exit:B、exit:A。它说明第三次尝试发生后，先前成功的两个入口会按后进先出的顺序退出。捕获到的异常消息仍是 C failed，且 active 为空，证明本例既保留失败信号，也释放了先前的资源。
success 一行在两次进入之后先记录 body，再出现 exit:B、exit:A。正常完成也遵守相同清理顺序。只检查 active 为空并不足以证明顺序正确，所以代码同时断言完整事件列表，防止某个依赖后创建资源的清理动作被过早执行。
事件是教学用探针，实际程序可以检查文件句柄的 closed、连接池计数或自己维护的状态。关键是验证可观察的释放结果，而不只是看“程序没有再报错”。退出方法也可能失败，那是另一条需要单独设计与测试的异常路径。
清理栈不是业务回滚系统
这里的 __exit__ 返回 False，因此不会吞掉异常；别的上下文管理器可能具有抑制异常的语义，ExitStack 会保留它们原有的行为。若登记的是普通清理函数，可以用 callback，但那种回调不接收异常详情，也不能通过返回真值来抑制异常。
with ExitStack() 的作用域应覆盖实际使用资源的整个阶段。把资源带出作用域后继续使用，它们可能已经关闭。也不要依赖垃圾回收触发清理：栈的回调需要在离开 with 或明确关闭时执行，单纯失去对象引用并不是同一种保证。
关闭文件不等于撤销已写入的内容，释放连接也不等于取消已经提交的业务操作。本实验只证明同步资源的登记与逆序释放，未测试异步接口或事务恢复。选择它的理由应是资源数量动态且生命周期需要集中管理，随后仍要为具体业务定义失败后的状态。
