Python contextlib.chdir 临时切换目录后如何保证异常恢复

如果构建脚本或测试脚本只需要在某个目录里完成一小段工作，contextlib.chdir 可以把“切换目录”和“恢复目录”绑定到同一个 with 块。进入上下文时切到目标目录，离开上下文时恢复进入前的目录；代码块中抛出异常也会执行恢复动作。真正需要注意的是，当前工作目录属于进程级全局状态，因此这个工具适合短小的顺序代码，不适合让多个线程或异步任务同时改目录。

要保证异常恢复，关键是让所有需要临时目录的操作都位于 with contextlib.chdir(target) 内，并保持代码块短小、顺序执行。嵌套使用时它会按进入顺序保存目录、按退出顺序逐层还原，但不会替你吞掉业务异常。

消息是什么：chdir 把恢复动作放进上下文退出

contextlib.chdir 从 Python 3.11 开始提供。它是一个非并行安全的上下文管理器：进入时调用目录切换，退出时把工作目录恢复为进入前保存的值。官方文档还明确指出，它是可重入的，但由于工作目录是全局状态，不适合大多数线程或异步场景。

因此，标题里的“保证异常恢复”不是再写一个 except 去补目录，而是把目录生命周期交给 with。下面这个示例只演示语义，不代表在本文环境中执行过。

from contextlib import chdir
import os

target = "/srv/build/input"
before = os.getcwd()

try:
    with chdir(target):
        # 临时目录只覆盖这段顺序操作，退出时由上下文恢复目录。
        print(os.getcwd())
        raise RuntimeError("构建输入不完整")
except RuntimeError:
    # 异常仍然由外层接收；chdir 负责恢复，不负责吞掉异常。
    print(os.getcwd() == before)

适用场景：短小的构建、测试和文件处理片段

最适合的场景有一个共同点：任务需要依赖当前目录，但可以明确包在一个短小的同步代码块里。例如构建脚本进入某个工作区读取相对配置，或者测试临时进入样例目录调用只认当前目录的工具。上下文结束后，后续步骤继续使用原来的目录。

使用时可以把“会受当前目录影响的调用”集中在块内，把网络请求、线程创建、长时间等待和回调注册放到块外。这样目录状态的影响范围容易读，也更容易在代码审查中确认。

快速试用：用嵌套上下文验证恢复顺序

嵌套 chdir 的行为可以直接按栈来理解。外层先保存目录 A 并切到目录 B，内层再保存目录 B 并切到目录 C；内层退出回到 B，外层退出回到 A。即使内层抛出异常，退出链仍然按照相反顺序执行。

from contextlib import chdir
import os

root = "/srv/project"
cache = "/srv/project/cache"

with chdir(root):
    # 外层保存调用前目录，当前目录暂时变为项目根目录。
    print("outer:", os.getcwd())
    with chdir(cache):
        # 内层再保存外层目录，异常离开时先回到 root。
        print("inner:", os.getcwd())
    # 内层已经恢复，外层代码仍在 root 中。
    print("after inner:", os.getcwd())

# 外层退出后恢复进入 with 前的目录。
print("after outer:", os.getcwd())

和旧方案对比：finally 仍然有价值，但职责不同

在没有使用 contextlib.chdir 的旧代码中，常见写法是先保存目录，再在 finally 中调用 os.chdir 恢复。这个方案并不是错误，尤其适合需要自定义上下文协议、记录额外状态或兼容旧 Python 版本的代码。

import os

old_dir = os.getcwd()
try:
    os.chdir("/srv/project")
    # 旧写法把临时操作放在 try 中，避免切换后遗漏恢复。
    build_one_target()
finally:
    # 无论 build_one_target 是否抛错，都恢复入口目录。
    os.chdir(old_dir)

两种写法的核心保证相同：恢复动作必须在退出路径上。contextlib.chdir 的优势是把这套协议封装成可嵌套的上下文，调用位置更接近资源的作用域；finally 则能让你把多个清理动作编排在同一个退出段中。无论选择哪种，都不要把恢复逻辑放在只会成功执行的下一行。

采用风险：全局工作目录会影响其它执行单元

需要把风险边界说清楚：chdir 改的是进程当前工作目录，不是某个局部变量。一个线程进入上下文后，另一个线程可能在同一时间看到变化后的目录；异步任务在 await 后恢复执行时，也可能已经被别的任务改变目录。生成器在上下文内主动 yield 还会让执行权暂时交给外部代码。

如果任务本身支持显式传入工作目录，应优先使用那个参数，让目录成为调用的局部配置，而不是改变进程状态。只有当依赖的 API 或外部工具确实只读取当前目录时，才考虑用 chdir，并把上下文限制在无并发、无异步切换的短区间。

落地清单：把恢复保证写成代码边界

1. 确认 Python 版本满足 contextlib.chdir 的使用条件；旧版本用显式 try/finally 封装。
2. 进入上下文前不要启动会并发执行的线程、任务或回调。
3. 把读取相对文件、调用外部工具等依赖当前目录的语句集中放在 with 内。
4. 异常只在确实需要转换或记录时处理；不要为了证明目录恢复而误吞原始异常。
5. 为嵌套场景写清楚外层和内层目录的预期，避免在多个函数之间隐式共享当前目录。

常见问题

代码块抛异常后，chdir 还会恢复目录吗？

会。上下文退出处理仍会运行，目录恢复和异常传播是两个独立动作；除非外层代码显式捕获异常，否则原异常仍会继续向外抛出。

嵌套 chdir 会恢复到最外层目录吗？

会按层恢复。内层先回到进入内层前的外层目录，外层再回到进入外层前的目录，不能把它理解为所有层级直接跳回同一个固定目录。

为什么异步函数里使用 chdir 容易出问题？

因为当前工作目录是共享的进程状态，任务在 await 期间可能让其它任务运行；恢复后看到的目录不一定还是自己进入上下文时设置的目录。

用 finally 自己恢复和 contextlib.chdir 哪个更好？

短小、顺序、可嵌套的目录作用域适合 contextlib.chdir；需要兼容旧版本或把目录恢复和其它清理动作统一编排时，显式 try/finally 更灵活。