Go fuzz 运行很慢时怎么缩小语料和执行范围

Go fuzz 一旦进入探索阶段，默认行为很容易让人误以为“卡住了”：它会先跑 seed corpus，再持续变异输入；如果没有失败，探索可能一直继续。处理这类慢运行，重点不是盲目删测试，而是把范围拆成四个旋钮：目标 fuzz、探索时长、失败输入最小化时长和并行度。

先用 go test -run=FuzzDecode 确认现有语料能通过，再用 go test -run=^$ -fuzz=^FuzzDecode$ -fuzztime=30s -parallel=1 做一次受控探索。语料只保留能覆盖不同入口的种子，失败后的最小化另用 -fuzzminimizetime 限制。

先只运行目标 fuzz，而不是整包无限跑

FuzzXxx 在没有 -fuzz 时像普通测试一样执行 seed corpus；真正开启探索要给 -fuzz 一个能匹配目标的正则。排查慢问题时，先把普通回归和探索分开：

go test -run=FuzzDecode

# 只开启 FuzzDecode，-run=^$ 用来跳过同包其他普通测试
go test -run=^$ -fuzz=^FuzzDecode$ -fuzztime=30s -parallel=1

第一条命令能回答“已有种子是否本身就慢或失败”；第二条才会进入覆盖率引导的输入变异。^FuzzDecode$ 比宽泛的 -fuzz=Fuzz 更适合定位，因为后者可能匹配多个 fuzz 函数。

用 -fuzztime 给探索设置硬上限

Go 官方文档把 -fuzztime 定义为 fuzz target 的总运行时间或迭代次数。短反馈可以用秒数，想按固定工作量比较两次结果，也可以用迭代次数。没有上限时，未发现失败的 fuzz 可能持续到手动停止。

# 本地快速反馈：最多探索 30 秒
go test -run=^$ -fuzz=^FuzzDecode$ -fuzztime=30s

# 对比两次运行的执行量，而不是对比墙上时间
go test -run=^$ -fuzz=^FuzzDecode$ -fuzztime=100000x

不要把 -fuzztime 当成普通测试超时：它限制的是 fuzz 探索预算，不会替你修复一个单次调用就很慢的 fuzz target。若每个输入都访问网络、写共享文件或依赖全局状态，应该先把 target 改成快速、确定且可并行调用的纯本地检查。

语料要少而有覆盖，最小化单独限时

seed corpus 有两种常见来源：代码里的 f.Add，以及 testdata/fuzz/FuzzDecode 下的语料文件。两者都会在普通 go test 中执行，也会作为变异起点。删语料时不要按文件数量机械清空，应按“是否覆盖新的输入形态或业务分支”保留。

func FuzzDecode(f *testing.F) {
    // 只放能覆盖不同格式的短种子，避免把重复样例交给变异器。
    f.Add([]byte("{}"))
    f.Add([]byte("[]"))

    f.Fuzz(func(t *testing.T, data []byte) {
        // fuzz target 应保持本地、快速、确定，避免共享可变状态。
        _ = decode(data)
    })
}

若某次失败触发的输入最小化阶段过久，可以加 -fuzzminimizetime=5s。它不是减少 seed、也不是缩短探索，只控制失败样例被缩减到更小形式时允许消耗的预算。

用 -parallel 控制机器压力并建立速查清单

-parallel 控制 fuzzing 进程的并行数量，默认值与 GOMAXPROCS 有关。开发机风扇突然拉满、CI 与其他任务争抢 CPU 时，先设为 1 或 2；等 target 确定且语料稳定后，再逐步提高。并行度变小会降低单位时间的探索量，但更容易比较和复现。

我通常保留三条命令：go test -run=FuzzDecode 做种子回归，go test -run=^$ -fuzz=^FuzzDecode$ -fuzztime=30s -parallel=1 做短探索，失败后再按输出的 fuzz 子测试名用 -run 单独复现。每次记录目标名、语料变动、时间预算和并行度，下一次才知道“变慢”究竟来自输入变多、target 变重，还是机器并行度变化。

常见问题

为什么设置了 -fuzztime 还是先运行一段时间？

开启 fuzz 前需要先建立 seed 的基线覆盖，这段时间属于准备阶段；如果单个 seed 就很慢，应先减少语料或优化 target。

-fuzzminimizetime 能不能限制整个 fuzz？

不能。它只约束失败输入的最小化过程；整个探索应使用 -fuzztime。

把 -parallel 调成 1 会不会改变测试结论？

它主要改变并行执行量和速度，不应改变一个快速、确定的 target 的正确性；若结果随并行度变化，优先检查全局状态、临时文件和外部依赖。

Go fuzz 慢时，先缩小“要跑什么”，再限制“跑多久”，最后才调整“同时跑多少”。语料整理应服务于覆盖边界，而不是追求目录里文件越少越好。