多个 with 嵌套时退出按后进先出顺序，逗号语法为并行进入、右到左退出；__exit__ 返回 True 抑制异常；ExitStack 用于动态管理不确定数量的上下文。
多个 with 语句嵌套时，退出顺序是反向的
Python 的 with 语句在退出时会按「后进先出」顺序调用各对象的 __exit__ 方法。这意味着最外层的 with 最晚执行清理，最内层的最先执行——这点和函数调用栈一致，但容易被忽略。
常见错误现象：你打开两个文件，想让日志文件最后关闭（确保写入完成），却把日志 with 写在了外层，结果日志文件提前关闭，后续写入失败。
- 正确做法：把依赖后置操作的资源放在更内层
- 若需显式控制顺序，避免深度嵌套，改用逗号语法或上下文管理器组合
- 注意：异常发生时，所有已进入的
__exit__仍会被调用，但不会跳过中间层
用逗号写在同一行的 with 不等于嵌套，而是并行进入
with open('a.txt') as f1, open('b.txt') as f2: 这种写法看起来像语法糖，但它实际等价于「同时进入两个上下文」，而非嵌套。两者的 __enter__ 按从左到右顺序调用，__exit__ 则从右到左调用。
使用场景：需要多个独立资源（如读写不同文件、数据库连接+临时目录）且无依赖关系时，这种写法更简洁、可读性更高。
- 如果某个
__enter__抛异常，右边未执行的不会进入，已进入的会正常退出 - 不能用于需要条件分支控制的上下文（比如只在满足某条件时才打开第二个文件）
- 不支持混合类型上下文管理器混用时的精细错误处理（比如一个抛
OSError，另一个抛ValueError）
自定义上下文管理器中 __exit__ 的返回值决定是否压制异常
__exit__(self, exc_type, exc_value, traceback) 返回 True 时，会吞掉当前异常，程序继续往下走；返回 None 或 False 则异常照常传播。这是很多新手调试失败的关键点。
容易踩的坑：写了 logging.exception(...) 就以为完事了，却忘了加 return False，导致异常被静默吞掉，后续逻辑莫名跳过。
- 仅在你明确知道该异常可安全忽略时才返回
True - 不要在
__exit__中重新抛异常（raise），这会覆盖原始异常链 - 若需转换异常类型，应捕获后 raise 新异常，并设
__cause__或__suppress_context__
用 contextlib.ExitStack 动态管理不确定数量的上下文
当你要打开的文件数、数据库连接数或锁的数量在运行时才能确定，硬写嵌套或逗号语法就不可行了。ExitStack 是标准库提供的动态上下文管理方案。
from contextlib import ExitStackfilenames = ['a.log', 'b.log', 'c.log'] with ExitStack() as stack: files = [stack.enter_context(open(f)) for f in filenames]
所有文件会在 with 结束时自动关闭，顺序与 enter_context 调用相反
for f in files: f.write('done\n')性能影响很小，但要注意：
enter_context返回的是上下文对象本身，不是新包装器；若某个__enter__失败，前面成功的仍会按逆序退出。
- 适合批量资源管理、测试中临时打补丁（
stack.callback）、条件式上下文注册 - 不能替代明确的
with语句做资源声明——它不提供变量绑定语法糖 - 若中途调用
pop_all()，需自行保管返回的上下文管理器列表并手动退出
复杂的地方往往不在「怎么写」，而在「谁先关、谁后关、异常来了谁扛、没扛住又传给谁」——这些细节藏在 exit 返回值、嵌套层级、以及 ExitStack 的调用时序里。
