Go testing.F 失败语料保存在哪里

运行 go test -fuzz=FuzzParse 后，失败输入通常不在某个神秘的临时目录里：优先检查当前包的 testdata/fuzz/FuzzParse/。如果包目录不可写，例如代码来自只读模块缓存，Go 会把失败输入写到 fuzz cache；而持续扩展覆盖率的输入本来就由 Go 放在构建缓存中。先分清这两个位置，排查时就不会把项目语料和缓存混在一起。

失败语料和 fuzz 缓存不是一回事

一个 fuzz 测试有三类容易混淆的输入。f.Add 注册的是源码里的 seed；包目录下的 testdata/fuzz/FuzzParse/ 里的文件也是 seed corpus，普通 go test 默认会执行它们。引擎在 fuzzing 过程中找到的覆盖率扩展输入，则由 Go 写入构建缓存的 fuzz 子目录，主要服务于后续 fuzzing，不是团队应该直接提交的测试样本。

真正失败时，Go 会尝试把导致失败的输入写入 testdata/fuzz/FuzzParse/。这个目录写不进去时，才会回退到 fuzz cache。因此“在哪里”取决于包是否可写；“应该放在哪里”则取决于你是否要把它变成长期回归样本。

先用测试名和哈希确认文件归属

失败日志里通常会出现类似 FuzzParse/7d3e... 的标识。前半段是 fuzz 测试名，后半段是该输入的文件名哈希。不要只在项目根目录搜索一串哈希，先进入定义 FuzzParse 的包，再检查：

# 用当前模块的缓存配置辅助定位；这里只读取配置，不会清理任何文件
go env GOCACHE

# 查看项目内可提交的 seed corpus；目录名要与 Fuzz 函数名一致
find ./testdata/fuzz/FuzzParse -maxdepth 1 -type f -print

# 按日志中的完整标识只重跑这一条失败输入
go test -run='^FuzzParse/7d3e你的实际哈希$'

如果项目目录里没有对应文件，先看失败时包是否来自模块缓存、挂载目录或只读工作区，再结合 go env GOCACHE 找到 Go 管理的缓存根。不要把缓存目录里的所有文件都复制进项目，它们包含覆盖率驱动的中间输入，生命周期和回归样本不同。

语料文件为什么能直接对应到参数

corpus 文件第一行是编码版本，后面的每一行对应 fuzz target 的一个参数。例如 target 接收 string 和 int，文件就会按顺序保存这两个值。类型顺序不对，Go 不能把它当作这个 fuzz 测试的 seed。

go test fuzz v1
string("空输入边界")
int(3)

f.Add 与文件语料必须使用完全相同的参数类型和顺序。对于字节切片、字符串或多参数输入，阅读文件时重点核对第一行后的类型标记；这比只看文件名更可靠。

稳定失败输入应回收到项目 corpus

如果这个输入代表一个已经确认的回归问题，应该把它保留在包内的 testdata/fuzz/FuzzParse/，并在提交说明中写清触发条件。这样以后普通 go test 也会执行它，不依赖某台机器的 GOCACHE。反过来，单纯为了让 fuzz 引擎探索更多路径而产生的覆盖率样本，继续交给缓存管理。

需要清理缓存时使用 go clean -fuzzcache，不要手动删除整个构建缓存。清理只影响 Go 保存的 fuzz 数据，不会删除已经提交到 testdata/fuzz 的回归语料。

相关问题

为什么普通 go test 也会跑失败语料？

因为 testdata/fuzz/FuzzName 中的文件属于 seed corpus；fuzzing 关闭时，Go 仍会把它们交给 fuzz target 执行。

找不到失败文件是不是说明测试没有保存？

不一定。包目录只读时，失败输入可能被写入 fuzz cache；先确认包路径权限，再查看 go env GOCACHE。

可以只靠哈希恢复输入吗？

哈希用于定位和重跑，不能反推出原始内容。要保留输入，应保存 corpus 文件本身或把它整理进项目的 testdata/fuzz/FuzzName。