模糊测试并发运行时临时文件冲突的修复

同一个 Go fuzz target 单独跑种子输入时正常，启用 -fuzz 后却偶发“文件不存在”、内容不一致或解析结果漂移，最常见原因之一是多个 worker 共用了同一个临时文件名。一个 worker 刚写完，另一个可能马上截断、覆盖或删除它。

不要用 filepath.Join(os.TempDir(), "case.bin") 作为 fuzz target 的共享路径。优先在每次调用里创建 t.TempDir()，再把稳定文件名放进这个独立目录；同一次调用需要多个临时文件时，再使用 os.CreateTemp。

官方文档：https://go.dev/doc/security/fuzz/

固定临时文件名为什么只在 fuzz 时出错

Go 官方文档明确说明，启用模糊测试后，fuzz target 会由多个 worker 并行调用，默认并行进程数与 GOMAXPROCS 相关。目标函数还应保持快速、确定，并且不能依赖跨调用保留的全局状态。

下面的写法表面上有写入和删除，实际上所有调用都指向同一个 payload.bin。os.WriteFile 会截断已存在的文件；defer os.Remove 也可能删掉另一个 worker 正在使用的文件。

func FuzzDecodeFile(f *testing.F) {
    f.Add([]byte("seed"))

    f.Fuzz(func(t *testing.T, data []byte) {
        // 错误示例：所有 worker 共享同一个固定路径。
        path := filepath.Join(os.TempDir(), "payload.bin")
        if err := os.WriteFile(path, data, 0o600); err != nil {
            t.Fatal(err)
        }
        // 这个删除动作可能影响另一个并发调用。
        defer os.Remove(path)

        if _, err := decodeFile(path); err != nil {
            t.Fatal(err)
        }
    })
}

这类问题通常具有非确定性：同一个输入单独回放可能通过，因为冲突依赖其他 worker 的时机，而不是输入内容本身。

最小修复是每次调用使用 t.TempDir

t.TempDir() 为当前测试返回临时目录，目录会在测试及其子测试结束后自动移除；同一个测试连续调用它，也会得到不同目录。fuzz target 收到的第一个参数正是 *testing.T，所以可以直接使用。

func FuzzDecodeFile(f *testing.F) {
    f.Add([]byte("seed"))

    f.Fuzz(func(t *testing.T, data []byte) {
        // 每次 fuzz 调用都有独立目录，固定文件名不再跨调用冲突。
        path := filepath.Join(t.TempDir(), "payload.bin")
        if err := os.WriteFile(path, data, 0o600); err != nil {
            t.Fatal(err)
        }

        got, err := decodeFile(path)
        if err != nil {
            t.Fatal(err)
        }
        // 断言只依赖当前输入和当前目录中的文件。
        if len(got) == 0 && len(data) != 0 {
            t.Fatalf("decode returned empty output for %d bytes", len(data))
        }
    })
}

这里不需要再写 defer os.RemoveAll。目录清理由 testing 包负责，失败时的清理路径也更统一。文件名仍可保持 payload.bin，因为真正需要唯一的是目录命名空间，而不是业务代码看到的文件名。

同一次调用有多个文件时再用 os.CreateTemp

如果一次 fuzz 调用会拆出多个片段，仅有独立目录还不够：目录内部也不能反复写同一个文件。os.CreateTemp 会根据模式生成唯一名称，并以读写方式打开文件。官方文档说明，多程序或 goroutine 同时调用时不会选择同一个文件名。

func writeChunk(t *testing.T, dir string, data []byte) string {
    t.Helper()

    // 星号位置会替换为随机字符串，避免同一目录内重名。
    file, err := os.CreateTemp(dir, "chunk-*.bin")
    if err != nil {
        t.Fatal(err)
    }
    path := file.Name()

    // 写入失败也要关闭句柄，错误直接归到当前 fuzz 输入。
    if _, err := file.Write(data); err != nil {
        file.Close()
        t.Fatal(err)
    }
    if err := file.Close(); err != nil {
        t.Fatal(err)
    }
    return path
}

使用 t.TempDir() 作为 CreateTemp 的目录参数后，文件会落在当前 fuzz 调用的隔离范围里，目录最终仍由 testing 包清理。

被测代码写死 os.TempDir 时要改成目录注入

如果冲突发生在生产函数内部，仅修改测试文件还不够。更稳妥的接口是让调用方传入工作目录，或者把文件创建封装为依赖。测试传 t.TempDir()，生产环境再传经过配置的目录。

func DecodeBytes(workDir string, data []byte) ([]byte, error) {
    // 稳定文件名只在调用方提供的工作目录中有效。
    path := filepath.Join(workDir, "payload.bin")
    if err := os.WriteFile(path, data, 0o600); err != nil {
        return nil, err
    }
    return decodeFile(path)
}

func FuzzDecodeBytes(f *testing.F) {
    f.Add([]byte("seed"))

    f.Fuzz(func(t *testing.T, data []byte) {
        // 测试显式注入独立目录，移除对全局临时路径的依赖。
        if _, err := DecodeBytes(t.TempDir(), data); err != nil {
            t.Fatal(err)
        }
    })
}

这种改法还能让普通单元测试复用同一接口，并使目录权限、剩余空间和清理策略更容易单独测试。

怎样确认修复针对的是并发冲突

可以提高 -parallel 复查目标，但不要把“跑久了没报错”当成唯一证明。还应检查代码里是否残留固定全局路径、包级可变变量和跨调用缓存。下面只是建议的复现命令，不是本文生成图片的运行证据。

# 提高 fuzz worker 数量，观察并发条件下是否仍有文件冲突。
go test -fuzz=FuzzDecodeFile -parallel=8 -fuzztime=30s

# 单独回放一个失败语料，检查结果是否由输入本身决定。
go test -run='FuzzDecodeFile/失败语料名称'

若隔离临时目录后问题仍存在，应继续排查共享端口、固定数据库名、全局随机数源、包级 map、缓存目录和外部服务账号。t.TempDir() 只能隔离文件目录，不能自动隔离所有共享状态。

常见问题

能不能用输入哈希当临时文件名

不建议把它当成主要修复。相同输入可能被重复执行，截断后的短哈希也可能碰撞；更重要的是，不同 worker 仍共享同一个父目录。独立目录加稳定文件名更直观。

t.TempDir 会让模糊测试变慢吗

频繁创建目录确实有文件系统成本。如果被测逻辑并不需要真实文件，优先把接口改为接收 io.Reader 或字节切片；必须测试文件行为时，再接受这部分隔离成本。

可以在 f.Fuzz 外面只创建一次 TempDir 吗

不要让所有调用写同一个目录。*testing.F 的设置阶段适合准备只读且不变的资源；会被目标修改的文件应在每次 *testing.T 调用内创建。

os.CreateTemp 后还要删除文件吗

如果文件位于 t.TempDir() 中，目录会自动清理；但文件句柄仍要及时关闭。若直接把空字符串作为目录参数，则调用方仍负责删除该文件。

结论

并发 fuzz 的临时文件冲突，本质是多个调用共享了可写命名空间。把 t.TempDir() 放进 fuzz target，可以先隔离每次调用；目录内需要多个文件时用 os.CreateTemp；生产函数若写死全局临时目录，则改为显式传入工作目录。修复后，失败应重新由输入决定，而不是由 worker 的碰撞时机决定。

参考：https://go.dev/doc/security/fuzz/、https://pkg.go.dev/testing#T.TempDir、https://pkg.go.dev/os#CreateTemp