Go testing.T.Chdir 在子测试中为什么会影响父测试

如果你在子测试里调用了 t.Chdir("testdata")，却发现父测试里的相对路径也变了，通常不是 t.Run 把目录“传回”了父测试，而是因为当前工作目录本来就是整个测试进程的共享状态。父子测试只是组织关系，不能把进程级目录自动隔离成每个测试一份。

testing.T.Chdir 的实际行为是调用 os.Chdir，并登记一个 Cleanup 在测试结束时恢复原目录；Unix 下还会在测试期间同步更新 PWD。因此，子测试执行期间，进程内其他仍在运行的代码都可能观察到这次切换。Go 官方文档也明确说明，Chdir 不能用于并行测试或带有并行祖先的测试。

一句话判断：子测试可以暂时改变目录，但这个目录是进程共享资源；只有在子测试结束并执行 Cleanup 后，才会恢复到它调用 Chdir 时保存的目录。

先把“父测试被影响”拆成两个时间点

一个父测试调用 t.Run 时，子测试函数会在单独的测试 goroutine 中执行。对于没有调用 t.Parallel 的子测试，父测试会等待 t.Run 返回，所以父测试的后续代码通常看不到子测试临时目录；但在子测试运行期间，工作目录已经被整个进程改掉了。

真正容易暴露问题的是两类代码：父测试在另一个 goroutine 中读取相对路径，或者同一测试进程里存在不受测试树同步约束的代码。此时“父测试”不是一个独立的进程，只是一个逻辑节点，它和子测试共享同一个当前工作目录。

子测试调用 Chdir 后，Cleanup 恢复到哪里

可以把 t.Chdir 看成“保存当前目录、切换目录、注册恢复动作”三件事。它保存的是调用这一刻的目录，不是测试进程启动时的目录。因此，子测试的恢复目标取决于它开始时父测试处于什么目录。

package workdir_test

import (
    "os"
    "path/filepath"
    "testing"
)

func TestNestedChdir(t *testing.T) {
    root, err := os.Getwd()
    if err != nil {
        t.Fatal(err)
    }

    parentDir := t.TempDir()
    childDir := t.TempDir()
    t.Chdir(parentDir) // 父测试先切换；父 Cleanup 会记住 root

    t.Run("child", func(t *testing.T) {
        t.Chdir(childDir) // 子 Cleanup 会记住 parentDir

        got, err := os.Getwd()
        if err != nil {
            t.Fatal(err)
        }
        if got != childDir {
            t.Fatalf("当前目录 = %q，想要 %q", got, childDir)
        }

        // 用绝对路径访问临时目录，避免把共享 cwd 当成参数传递。
        marker := filepath.Join(childDir, "marker.txt")
        if err := os.WriteFile(marker, []byte("child"), 0o600); err != nil {
            t.Fatal(err)
        }
    })

    // 子测试结束后，子 Cleanup 已把目录恢复为 parentDir。
    got, err := os.Getwd()
    if err != nil {
        t.Fatal(err)
    }
    if got != parentDir {
        t.Fatalf("子测试返回后目录 = %q，想要 %q", got, parentDir)
    }
}

上例中，子测试结束时先执行自己的 Cleanup，所以目录从 childDir 回到 parentDir。整个父测试结束后，父测试自己的 Cleanup 再把目录从 parentDir 恢复到 root。这里的关键不是“子测试影响了父测试的永久状态”，而是父子测试对同一个进程级状态分别注册了自己的恢复边界。

父子测试都 Chdir 时，为什么像栈一样恢复

当父测试先切换目录、子测试再切换目录时，最容易犯的错误是把子测试的恢复目标想成“项目根目录”。实际上它只会恢复到自己调用 Chdir 前看到的目录，也就是父测试的目录。

这种行为适合“整个测试组都在一个临时目录下、某个子测试再进入更深一层目录”的串行结构，但不适合把 Chdir 当成普通函数参数。只要还有代码并行运行，目录状态就可能在读取相对路径的中途改变。

反例：把 Chdir 和 t.Parallel 放在同一棵树里

下面的写法表达了一个看似合理的意图：每个子测试进入自己的临时目录，再并行执行。但它把进程级状态和并行调度放在了一起。

func TestParallelDirectories(t *testing.T) {
    cases := []struct {
        name string
        file string
    }{
        {name: "one", file: "one.txt"},
        {name: "two", file: "two.txt"},
    }

    for _, tc := range cases {
        tc := tc
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel() // 并行子测试不能再依赖进程级 Chdir

            dir := t.TempDir()
            // 不要在这里调用 t.Chdir；为每次操作传入绝对路径。
            path := filepath.Join(dir, tc.file)
            if err := os.WriteFile(path, []byte(tc.name), 0o600); err != nil {
                t.Fatal(err)
            }
        })
    }
}

官方限制已经给出答案：Chdir 不能用于并行测试，也不能用于拥有并行祖先的测试。即使某个版本或某种调度下暂时没有出现错误，也不应把偶然的执行顺序当作隔离保证。

更稳妥的组织方式

第一选择是把目录需求变成显式参数。让被测函数接收目录路径，或者让测试辅助函数接收 dir string，这样并行子测试只操作自己的绝对路径，目录状态不会藏在进程全局变量里。

第二选择是用 t.TempDir() 创建临时目录，但不一定要切换进程目录。它会在测试结束后清理目录，适合配置文件、缓存文件和导入样本等测试数据。

只有当被测代码本身无法传入目录、确实读取当前工作目录时，才考虑 t.Chdir。这时应把相关测试放在非并行的测试组中，并让所有依赖相对路径的动作集中在一个清晰的串行边界内。

最后用这份清单判断

• 子测试改变的是整个测试进程的当前工作目录，不是只属于它的上下文值。
• 子测试的 Cleanup 恢复到它调用 Chdir 前的目录；父测试的 Cleanup 再恢复父测试自己的上一级目录。
• 父测试在 t.Run 返回后通常能看到恢复后的目录，但其他并发代码不应依赖这个时序。
• t.Parallel、并行祖先和手工启动的共享状态 goroutine，都应该视为 Chdir 的高风险组合。
• 能传绝对路径就不要切换工作目录；必须切换时，把范围收窄到串行测试组。

相关问题

t.Chdir 会自动清理临时目录吗？

不会。t.Chdir 负责恢复当前工作目录；临时目录的生命周期应交给 t.TempDir()，文件路径则建议用 filepath.Join 明确构造。

子测试结束后父测试为什么还在临时目录？

如果父测试在子测试前已经调用了 t.Chdir，子测试只会恢复到父测试当时的目录。等父测试本身结束，父测试注册的 Cleanup 才会继续恢复到更外层目录。

可以用 defer 手动恢复目录吗？

不建议用手工恢复替代 t.Chdir 的测试生命周期管理，尤其不要在并行测试里这样做。更安全的方向是去掉当前目录依赖；必须保留时使用非并行测试，并让恢复动作绑定在测试边界上。