Go fuzz 测试一直不收敛如何缩小输入空间

Go fuzz 测试一直不收敛，先别急着把 -fuzztime 调得更大。很多时候真正失控的是输入域：种子覆盖太窄、随机字节无法通过业务解析，或者单次测试把超大输入带进了昂贵路径。收窄输入空间的正确方向，是保留能触发关键分支的边界样本，跳过不属于测试契约的输入，并让 fuzz target 保持快速、确定。

把“收敛”理解为有限预算内更快触达有价值分支、更快复现失败，而不是要求 fuzz 引擎停止产生新输入。

先分清是覆盖率探索慢，还是输入域太宽

Go 原生 fuzzing 从 Go 1.18 起进入标准工具链。go test -fuzz 会反复变异种子输入，并利用覆盖率反馈保留能扩展路径的样本；日志中的 new interesting 变多，说明引擎还发现了新的覆盖价值，不等同于测试失败。真正需要处理的信号通常是：基线覆盖很低、绝大多数输入在解析入口被拒绝、单次调用耗时随长度急升，或失败样本大到难以回放。

因此，先画出测试契约：输入允许哪些类型、最大长度是多少、哪些格式才是业务关心的、哪些分支必须被覆盖。Go 的 fuzz target 要求快速、确定，且不应依赖跨调用保留的可变状态。若目标函数本身接受任意字符串，就不应为了“收敛”把所有 Unicode 或空值删掉；只有域外数据才应该跳过。

用小而互补的 seed corpus 固定探索起点

种子语料不是越多越好。它的作用是让基线覆盖尽快进入有意义的分支，并为变异器提供不同形状的起点。可以把空值、最短合法值、刚好越界的长度、包含分隔符的值和一条曾经修复过的回归输入分开考虑；不要把几十个只改一个字符的样本堆在一起。

func FuzzDecode(f *testing.F) {
    // 种子覆盖合法边界、分隔符和一个历史回归形状。
    f.Add([]byte(""))
    f.Add([]byte("id=42;active=true"))
    f.Add([]byte("id=;active=false"))

    f.Fuzz(func(t *testing.T, data []byte) {
        // 输入域由协议长度约束；超出契约的样本不参与断言。
        if len(data) > 4096 {
            t.Skip("input is outside the protocol limit")
        }
        record, err := Decode(data)
        if err != nil {
            // 非法格式不是本测试要寻找的失败，交给其他测试覆盖。
            t.Skip("invalid record")
        }
        if record.ID 

f.Add 的参数类型必须与 fuzz target 的参数完全一致；也可以把语料文件放进 testdata/fuzz/FuzzDecode。失败输入会被保存为 corpus 条目，后续不带 -fuzz 的普通测试也会回放它，所以这一步同时建立了回归入口。注意，t.Skip 只适合明确的域外输入；若某个输入本应被支持，却因为解析错误被跳过，就等于把 bug 隐藏了。

在入口约束长度和格式，但不要破坏有效边界

缩小空间有三层顺序：先限制明显无意义的长度，再用轻量解析判断格式，最后才进入昂贵的解码、数据库构造或递归路径。长度阈值应来自协议或业务契约，而不是凭感觉写一个很小的数字。对二进制协议，优先用 []byte；对文本协议，使用 string 并保留空串、非 ASCII、分隔符缺失等真正重要的边界。

还有一个容易忽略的边界：fuzz target 会在多个 worker 中以非确定顺序运行，不要把输入指针或可变切片保存到下一次调用，也不要依赖共享全局状态。否则即使输入空间已经收窄，复现仍可能抖动。

用固定预算和 corpus 回放判断是否变好了

不要用“跑得越久越好”作为唯一指标。可以先用固定预算运行一个目标：

# 只跑指定 fuzz target，并把探索预算固定为 30 秒。
go test -run=^$ -fuzz=FuzzDecode -fuzztime=30s

# 回放 f.Add 与 testdata/fuzz/FuzzDecode 中的种子及失败样本。
go test -run=FuzzDecode

比较两次调整前后的四项结果：同一预算内是否更早进入关键分支；无效输入占比是否下降；失败 corpus 是否更短、更容易复制；普通 go test 能否稳定重现。若只是 new interesting 继续增加，但每次调用很快、关键路径覆盖也在增长，那不是必须修复的“不收敛”。相反，若日志看似繁忙却几乎都卡在解析失败，就应重新设计种子和入口契约。

常见问题

把 f.Add 的样本删到只剩一个，会更快吗？

不一定。单个样本可能让基线覆盖变窄，变异器反而更难到达其他分支。应该保留少量形状不同、能解释业务边界的种子。

是否应该在 fuzz target 里直接 return？

域外输入最好用 t.Skip 明确表达“本次不测试”；对属于契约的输入则应继续断言，不能用 return 把潜在失败静默吞掉。

失败输入保存在哪里？

项目级语料通常位于 testdata/fuzz/FuzzDecode；如果该目录不可写，Go 会把失败条目放入构建缓存中的 fuzz cache。保留它并用普通测试回放，才算完成一次可复现修复。