Go fuzz 测试失败后怎样用自动保存的语料复现

Go fuzz 测试失败时，日志通常会告诉你两件关键事情：失败输入已写入 testdata/fuzz/，并给出一个可以再次运行的子测试名。这个文件不是一次性临时结果；它会作为 seed corpus 被普通 go test 默认执行。排查时先收好该文件，再关掉随机 fuzz，用确定性测试复现，定位会快很多。

失败日志里的语料文件到底保存在哪里

Go 原生 fuzz 的输入有两层。写在 f.Add 中、或放在 testdata/fuzz/FuzzParse 目录里的内容属于 seed corpus，运行普通 go test 时也会被执行。模糊测试过程中为了扩大覆盖率保留的 generated corpus 位于 $GOCACHE/fuzz，主要服务于继续 fuzz，不应直接当作项目回归文件。

因此看到下面这类日志时，先记住最后一段路径和 fuzz 测试名：

Failing input written to testdata/fuzz/FuzzParse/4b7c...
To re-run:
go test -run=FuzzParse/4b7c...

文件名是输入内容的稳定标识，不要手工改名后再猜测参数。先打开文件确认首行是 go test fuzz v1，后续每一行按 fuzz target 参数顺序保存一个值。

先用普通 go test，再精确重放失败输入

最稳妥的复现顺序是先运行不带 -fuzz 的测试。它会执行所有 seed corpus；如果只想观察某个 fuzz 测试，可以给 -run 一个名称。下面的示例故意保留小函数，让复现入口与真实工程中的解析函数结构一致：

package parser

import (
    "testing"
)

func FuzzParse(f *testing.F) {
    // 先放入一个合法种子，其他失败输入由 testdata/fuzz/FuzzParse 提供。
    f.Add("name=go")
    f.Fuzz(func(t *testing.T, raw string) {
        // 示例边界：没有等号时视为非法输入，方便观察失败语料复现。
        if raw == "" || !containsEqual(raw) {
            t.Fatalf("invalid pair: %q", raw)
        }
    })
}

func containsEqual(raw string) bool {
    // 只演示复现入口，真实项目可替换为自己的解析器。
    for _, r := range raw {
        if r == '=' {
            return true
        }
    }
    return false
}

在包目录执行：

# 先执行所有单元测试和 seed corpus，确认失败是否稳定
go test

# 只运行名为 FuzzParse 的 fuzz 测试，不开启随机输入生成
go test -run=FuzzParse

# 从日志给出的文件名精确重放一个失败子测试
go test -run='FuzzParse/4b7c...'

这里的第三条命令要替换成日志里的完整文件名。若普通 go test 已经失败，说明输入已成为可重复的 seed；若只有 go test -fuzz=FuzzParse 才失败，优先检查你是否误把输入放在了缓存目录，或者 fuzz target 是否依赖了全局状态。

怎样利用最小化输入看出真正触发条件

发现错误后，Go fuzz 引擎会尝试把输入缩小到仍能触发错误的形式。corpus 文件的格式类似下面的文本，它不是普通业务配置，首行版本标识不能删：

go test fuzz v1
string("name=go")

如果 fuzz target 接收的是 []byte、string、整数或布尔值，文件中每个值的类型和顺序必须与 f.Fuzz 的参数完全一致。常见误区是只复制最后一行字符串，却忘记原测试有第二个整数参数，结果 Go 会在读取 corpus 时直接报格式或类型错误。

复现时请把“输入最短”与“问题已解释”分开看。最小字符串可能只保留一个分隔符，真正的业务条件却是“字段为空后仍被当成有效键”。调试日志应记录解析分支、错误返回和资源状态；不要在 fuzz target 中保存可变参数，也不要依赖并发调用顺序，这些都会让同一个 corpus 看起来忽好忽坏。

修复后如何把失败语料变成长期回归

确认根因后，保留 testdata/fuzz/FuzzParse/ 文件，并把它和代码修复一起提交。修复前它应稳定失败，修复后普通 go test 应通过；之后仍可定期用受限时长的 go test -fuzz=FuzzParse -fuzztime=30s 寻找新分支。不要把 $GOCACHE/fuzz 整目录加入版本库，也不要为了让 CI 变绿而删除失败 seed。

Go fuzz 失败语料常见问题

为什么删掉语料后普通 go test 就不再失败？

因为你删掉的是项目内 seed corpus。它承载了曾经触发问题的具体输入；删除只是让测试失去回归样本，并不代表根因已经修复。

日志里的失败文件能直接改成 f.Add 吗？

可以把 corpus 文件中的值转换成与 fuzz target 参数一致的 Go 表达式，但没有必要为了复现而改写。保留原文件通常更适合二进制或较长输入，也能让普通 go test 自动执行。

为什么同一个 corpus 有时失败、有时通过？

先检查 fuzz target 是否快速、确定性，是否读写全局变量、时间或共享文件。Go 文档建议每次调用结束后不保留状态；如果输入本身不变而结果变化，问题多半在测试隔离而不是 corpus 文件名。