Go 解析函数边界用例漏测：用 fuzz seed 和回归语料固定崩溃输入

解析函数最容易出现一种“单测都绿了，线上却被奇怪输入打穿”的情况：样例覆盖了正常键值，却没有覆盖空字段、重复分隔符、超长片段或截断输入。Go 原生 fuzzing 的价值不只是随机喂数据，而是把发现的失败输入缩减并保存为 seed corpus，修复后由普通 go test 自动回放。本文用一个纯 key=value 解析场景，把这条链路固定下来。

先把解析函数的边界写成可测试的性质

先确定函数的契约，而不是马上打开 fuzz。下面的示例把第一段作为键、第二段作为值；没有等号返回错误，空键也返回错误。这里的性质很小：合法输入不能 panic，成功结果的键和值都非空，非法输入只能得到明确错误。

func parseRecord(s string) (key, value string, err error) {
    i := strings.IndexByte(s, '=')
    if i 

FuzzXxx 必须位于 _test.go，并通过 f.Fuzz 接收 *testing.T 和 fuzz 参数。string 是支持的参数类型之一，所以这里的 seed 也必须都是一个字符串。注意 f.Add 中的 x= 和 =missing-key 是有意的错误边界，它们验证的是“返回错误”，不是要求解析器接受所有输入。

用限定预算找出真正漏测的输入

先用普通测试跑 seed，确认样本本身没有把环境问题带进来：

go test -run=FuzzParse

再开启探索，并给自动化任务一个明确预算：

go test -fuzz=FuzzParse -fuzztime=30s

输出里的 execs 是已执行的输入数量，new interesting 表示扩展了覆盖范围的输入数量。它们是探索信号，不是业务正确率。真正需要留下的是失败原因和语料路径。失败可能来自 panic、断言失败或一次执行过慢；Go 会尝试缩减仍能触发问题的输入，并把结果写入 testdata/fuzz/FuzzParse。拿到文件名后，可以精确回放：

go test -run=FuzzParse/缩减语料文件名

这样排查就从“随机失败”变成了一个固定样本。若函数依赖全局 map、时间或网络，先拆出纯解析层，否则同一个 corpus 可能在不同机器上表现不一致。

把失败输入变成默认回归语料

发现问题后，先判断它属于哪条契约：是分隔符处理错、长度边界错，还是错误返回后仍继续使用了空结果。修复 parseRecord 后，不要把失败文件移走；目录中的 corpus 文件与 f.Add 种子一样，会在普通 go test 中执行。

go test
git add path/to/package/testdata/fuzz/FuzzParse

提交前至少确认三件事：失败文件的类型和 fuzz 参数顺序一致；修复后的函数对该输入不再 panic；测试没有依赖本地缓存才能通过。长期 fuzz 生成的 corpus 只在覆盖新路径时保留，不要为了“文件越多越专业”无限提交。

一张速查表收口工作流

这套做法适合纯解析、编码转换和输入校验。它不替代接口集成测试，也不意味着 fuzz 跑得越久就一定覆盖业务语义；高质量 seed、清晰性质和可回放语料，才是把一次崩溃变成长期收益的关键。

相关问题

f.Add 的输入和 f.Fuzz 参数可以使用不同类型吗？

不可以。seed 的类型和顺序必须与 fuzz target 的参数一致；需要换类型时，应同时调整 target 和 seed。

为什么普通 go test 也会触发 fuzz 失败？

因为 seed corpus 和 testdata/fuzz/FuzzParse 中的语料属于默认回归输入，不需要再次传入 -fuzz。

fuzz target 为什么要避免全局状态？

fuzz target 可能并行、且调用顺序不确定；依赖全局可变状态会让失败难以复现，也会污染其他输入的结果。