Go fuzzing 添加种子语料后怎样定位首次失败输入

Go fuzzing 失败后，最有价值的线索通常就在失败日志最后两行：一行是写入的语料文件路径，另一行是可以单独重放的 go test -run=FuzzName/hash 命令。先复制这条命令定位单个输入，再打开 testdata/fuzz/FuzzName 下的文件确认参数，通常比重新跑一轮随机 fuzz 更快。

为什么添加种子后普通 go test 也会执行

Go 的 fuzz 测试有两个相连的入口：不带 -fuzz 时，它像普通测试一样遍历已有种子；带 -fuzz=FuzzXxx 时，测试引擎再围绕种子变异输入并寻找新覆盖路径。种子不是一次性启动参数，而是测试的一部分，所以一个失败语料被写入后，下一次普通测试仍会遇到它。

这正是定位问题的关键：失败后不要先删除文件，也不要只看随机输入的打印结果。文件名和文件内容共同描述了可以复现的测试样本。

用 f.Add 和 testdata/fuzz 管好输入

简单、稳定的边界值适合直接写在测试里；需要长期保留、便于代码审查的样本适合落到目录。两种来源进入同一个种子集合，但参数类型必须与 fuzz 目标完全一致，顺序也不能交换。

func FuzzDecode(f *testing.F) {
    // 用短样本覆盖空值、分隔符和正常输入等基础路径。
    f.Add("", 0)
    f.Add("a:b", 1)

    f.Fuzz(func(t *testing.T, raw string, mode int) {
        // 目标函数应尽量确定性，失败时让 testing.T 保留现场。
        if _, err := Decode(raw, mode); err != nil && raw == "a:b" {
            t.Fatalf("decode failed: %v", err)
        }
    })
}

如果要手工放置目录语料，路径应是当前包内的 testdata/fuzz/FuzzDecode。文件第一行写 go test fuzz v1，后续每行按 fuzz 参数顺序写一个值。不要把任意原始文本直接改名塞进目录，否则测试框架无法按语料格式解码。

失败日志怎样指向首次失败输入

启动 fuzz 后，日志可能先报告最小化，再给出类似下面的重放路径：

Failing input written to testdata/fuzz/FuzzDecode/8c1f...
To re-run:
go test -run=FuzzDecode/8c1f...

这里的 FuzzDecode 是 fuzz 测试名，后面的 hash 是该语料的标识。先执行这条命令，而不是继续使用 -fuzz，可以把变量范围收窄到一个输入。然后打开同名文件，核对它是否包含多个参数，以及文件中的字符串、整数或字节值是否与目标函数签名一致。

“首次失败”不一定等于日志里最早出现的随机样本。引擎会尝试最小化，最终留下的是仍能触发失败的较小语料；真正的排查入口是最终的 hash、语料文件和测试日志三者。若单独重放时不再失败，优先检查测试是否依赖全局状态、时间、网络或并发顺序，这些都会破坏 fuzz 目标的确定性。

修复后如何让失败语料成为回归测试

定位到输入后，先保留语料文件，再修复被触发的代码。修复完成运行不带 -fuzz 的 go test，它会重新执行所有种子，包括刚刚保存的失败样本；通过后再用有限的 -fuzztime 做补充探索。

不要为了让流水线变绿而删除失败样本。只有确认它代表误报或测试契约已被有意修改时，才应在代码审查中说明删除理由。

常见问题

f.Add 的种子会和目录语料重复吗？

可能重复。它们都属于种子集合，重复样本不会带来新的覆盖价值，应该保留更容易读懂、维护位置更明确的一份。

为什么 go test -run=FuzzDecode 不能只跑一个失败输入？

这个写法通常会匹配该 fuzz 测试下的多个子测试。要精确定位，应使用日志给出的 FuzzDecode/hash 完整子名称。

什么时候应该继续跑 -fuzz？

当失败输入已经被修复、普通种子测试通过，并且目标函数具备确定性时，再用有限的 -fuzztime 扩大探索范围。