Go fuzz 测试为什么无法读取工作目录文件

Go fuzz 测试读取相对路径文件失败时，先不要把问题归因于 fuzz 引擎。更常见的原因是：你以为“工作目录”是模块根目录，但 go test 启动测试二进制时，当前目录是对应包的源代码目录。测试文件位于 internal/parser 时，os.ReadFile("testdata/case.json") 实际查找的是 internal/parser/testdata/case.json。

这条规则在普通测试、种子语料回放和真正的 go test -fuzz 中都应该按包目录理解。修复重点是把夹具放进包内 testdata，或者显式传入资源路径，不要在 fuzz 回调里改变整个进程的工作目录。

结论：相对路径要相对“被测包目录”组织；包内固定资源优先使用 testdata 或 go:embed，包外文件使用明确的绝对路径。

相对路径到底从哪里开始算

go test 会先构建测试二进制，再从对应包的源代码目录启动它。因此“我在模块根目录执行了命令”并不能改变测试进程里相对路径的语义。多包测试尤其容易暴露这个误会：每个包都有自己的目录基准。

建议把目录布局写成下面这样，让路径和测试包保持同一边界：

parser/
├── parser.go
├── parser_test.go
└── testdata/
    └── case.json

然后在 parser_test.go 中读取：

func loadFixture(t *testing.T) []byte {
	// 路径相对当前测试包，避免依赖 shell 的启动目录。
	data, err := os.ReadFile(filepath.Join("testdata", "case.json"))
	if err != nil {
		// 夹具缺失属于测试环境错误，直接让当前用例失败。
		t.Fatalf("读取测试夹具失败: %v", err)
	}
	return data
}

这里的代码需要导入 os、path/filepath 和 testing。如果文件放在模块根目录而测试包在子目录，直接写 ../ 只能碰巧工作，换包、换工作树或被工具单独启动后都容易失效。

为什么 fuzz 回调更不适合改工作目录

fuzz target 会被反复调用，官方建议它快速、确定，并且不要依赖共享状态。工作目录属于整个进程的全局状态；在回调中调用 t.Chdir，既不能解决资源定位设计问题，也会触碰 fuzz 的并发边界。新版本 testing API 会禁止在 fuzz target 中使用这类会影响进程环境的方法。

更稳妥的做法是让每次调用只依赖输入参数和只读资源：

func FuzzParseFile(f *testing.F) {
	// 种子输入只描述内容，不把全局目录状态带进 fuzz target。
	f.Add([]byte("name=value"))
	f.Fuzz(func(t *testing.T, input []byte) {
		// 每次调用都用内存输入，避免并发调用争用同一个可变文件。
		if err := parseConfig(input); err != nil {
			t.Skip("无效配置不属于本用例边界")
		}
	})
}

如果必须测试文件解析，可以在 fuzz target 外读取只读夹具，再把内容作为参数或不可变基准使用；不要让某一次输入改写共享文件，也不要依赖调用顺序。

包内资源用 testdata，固定内容可用 go:embed

Go 的 fuzz 语料本身约定放在 testdata/fuzz/。普通测试夹具也可以放在包下的 testdata，这样既符合测试目录习惯，又不会把相对路径误指向模块根目录。若内容是编译时固定资源，可以用 go:embed 完全绕开运行时工作目录：

import "embed"

//go:embed testdata/case.json
var fixture []byte

func FuzzDecode(f *testing.F) {
	f.Fuzz(func(t *testing.T, input []byte) {
		// fixture 来自编译产物，input 仍是本次 fuzz 调用的独立数据。
		if err := decodeWithFixture(fixture, input); err != nil {
			t.Skip("输入不满足解码前置条件")
		}
	})
}

go:embed 适合随代码发布、不会由用户替换的文件；它不是读取任意外部工作目录文件的通用替代品。需要测试部署目录、用户上传文件或临时生成文件时，应把路径作为配置或参数传入，并在测试开头用 filepath.Abs 转成清晰的绝对路径。

出现“找不到文件”时按这三点判断

第一，确认测试包和文件是否同级：把 testdata 放到包含 parser_test.go 的包目录，而不是只放在仓库根目录。第二，区分普通种子回放和 -fuzz 持续生成：失败语料由 Go 按 fuzz 目录规则保存，不要把它和自定义夹具混为一谈。第三，确认代码没有在 fuzz 回调中读写共享文件或切换工作目录。

可以把原则压缩成一张表：

常见问题

为什么我从模块根目录执行仍然失败？

命令的启动位置和测试二进制的工作目录不是同一个概念；测试进程以被测包目录作为相对路径基准。

能不能在 fuzz 回调里用 t.Chdir？

不建议，也不应把它当作修复方案。它修改整个进程的工作目录，而 fuzz target 需要适合并发、重复调用和确定性执行。

失败语料应该放在哪里？

按 Go fuzz 约定放在包目录的 testdata/fuzz/；普通固定夹具则放在包目录下的 testdata。

把“相对哪个目录”先说清楚，Go fuzz 的文件读取问题通常就能从路径猜测，变成可维护的测试资源约定。