Go fuzzing 的 F.Add 与种子语料怎么分工：初始样本、随机变异和回归保存

第一次给 Go 函数加 fuzz test 时，最容易混淆的是两件事：F.Add 写进去的样本，和 fuzzing 过程中引擎变异出来的输入，并不是同一种资产。前者是开发者明确知道值得覆盖的起点，后者是引擎为了扩大覆盖率生成的尝试；如果某个尝试触发了失败，它还会被保存成下次测试默认执行的回归样本。

F.Add 负责种子语料，F.Fuzz 负责接收 fuzz target，testdata/fuzz/FuzzReverse 负责保存可复现的语料文件；三者串起来，才是完整的 Go fuzzing 回路。

先把三类输入放回同一条测试链

Go 的 fuzz test 通常写成 FuzzXxx 函数。开发者先用 F.Add 注册能代表业务边界的初始样本，再调用一次 F.Fuzz 提供 fuzz target。执行期间，引擎会尝试变异这些输入；如果某个输入让断言失败，就会把它写进对应 fuzz test 的语料目录。

因此，F.Add 不是“再跑几组单元测试”的快捷写法，F.Fuzz 也不是一个可以反复调用的循环入口。每个 fuzz test 必须只有一个 fuzz target，且 F.Add 只能出现在它之前。

这条链的顺序只有一条：F.Add 先注册种子，F.Fuzz 再连接 fuzz target；普通测试和长时间 fuzzing 都会从这批起点开始。

种子样本应该描述边界，而不是凑数量

以字符串处理函数为例，可以放入空字符串、普通 ASCII、包含空格的字符串和多字节字符。样本的价值在于告诉引擎“这些形状值得从这里继续探索”，不是把常见输入重复十遍。官方要求种子参数类型与 fuzz target 参数一一对应，顺序也不能改变。

func FuzzReverse(f *testing.F) {
    f.Add("Hello, world")
    f.Add(" ")
    f.Add("你好，Go")

    f.Fuzz(func(t *testing.T, input string) {
        got := Reverse(input)
        if Reverse(got) != input {
            t.Fatalf("round trip failed: %q", input)
        }
    })
}

这里的 input string 与三个 F.Add 的参数类型一致。若把其中一个改成整数，测试会在注册种子时暴露契约错误，而不是等到业务断言失败后才发现。

为什么随机变异仍然需要种子语料

fuzzing 引擎不是从完全空白的输入开始。它会运行种子，观察覆盖情况，再对输入做变异，尝试走进新的分支。一个好的种子可以直接把引擎带到解析器的转义分支、UTF-8 边界或长度检查附近；但它不会替你定义函数应该满足的性质。

例如上面的性质是“反转两次应回到原字符串”。如果函数真正要保证的是“输出始终是合法 UTF-8”，就应在 fuzz target 里写出这个判断。F.Add 能提高探索起点，不能替代断言。

失败输入怎样变成可重复的回归样本

当 fuzzing 找到失败输入时，Go 会把它保存到 testdata/fuzz/FuzzReverse 这样的目录中。这个文件不是一次性日志，而是新的种子语料。修复函数后，直接执行 go test，普通测试流程也会再次运行它；只有它通过了，修复才算真正覆盖到这次缺陷。

失败输入的状态变化是“探索样本”到“回归样本”：它先触发 fuzz target，随后进入 testdata/fuzz/FuzzReverse，最后由 go test 反复验收。

这也是为什么不应随手删除目录里的失败样本。它记录的是曾经击穿过断言的具体输入。若产品行为已经有意改变，应先更新断言和说明，再决定是否替换该样本，而不是先清空语料让测试变绿。

普通 go test 与 go test -fuzz 的分工

go test 适合快速确认所有种子和已保存失败输入没有回归；go test -fuzz=FuzzReverse 才会在给定时间内持续生成并运行新的变异输入。两者都重要：前者是每次提交的短反馈，后者是主动寻找新边界的探索阶段。

三个容易把语料体系写乱的反例

第一，把需要昂贵网络服务的初始化放进 fuzz target。引擎会高频调用它，测试会变慢且结果受外部状态影响。第二，在 target 里修改全局切片或缓存，前一个输入留下的状态可能污染后一个输入。第三，只保留随机阶段发现的样本，不补充能说明业务边界的 F.Add，后来读代码的人就很难知道为什么从这些输入开始。

更稳的做法是让 target 保持快和确定，把资源准备放在外层；用 F.Add 表达少量、有意图的起点；把失败语料提交到版本库，让修复后的普通 go test 继续守住它。

常见问题：Go fuzzing 语料怎么维护

F.Add 必须写在 F.Fuzz 前面吗？

是。*testing.F 的配置和种子添加应在 F.Fuzz 前完成；进入 fuzz target 后，不能再把普通参数动态追加成种子。

失败输入会不会只在 fuzzing 模式下运行？

不会。保存到 testdata/fuzz/FuzzReverse 的语料会作为种子，在普通 go test 中也默认运行。

种子越多，fuzzing 就一定越有效吗？

不一定。种子应覆盖有意义的形状和边界；大量相似样本会拉长基础测试，却未必带来新的覆盖。

修复失败样本后还要保留它吗？

通常要保留。它是可复现的回归证据，除非业务契约已经改变，并且断言、说明和语料都同步调整。

把语料当成测试资产来管理

可以把这套分工记成一句话：F.Add 描述开发者知道的起点，F.Fuzz 承接自动探索，testdata/fuzz/FuzzReverse 留住曾经失败的证据。这样设计后，短时间的 go test 和长时间的 fuzzing 才能共享同一条可解释、可回归的测试链。