Go fuzz 测试运行时间过长的资源约束

Go 的 fuzz 测试如果没有主动设置预算，可能一直运行到发现失败样本或被人工中断。遇到“运行时间过长”，先不要把所有问题都归到 -timeout：真正控制 fuzz 阶段的是 -fuzztime，失败样本的压缩另有 -fuzzminimizetime，并发压力由 -parallel 影响，而单个输入过大则要在 Fuzz 目标里处理。

最实用的组合是：用 -fuzztime 给 fuzz 阶段设总预算，用 -fuzzminimizetime 限制失败样本最小化，用较小的 -parallel 控制 CPU 和内存，再用 -timeout 给整个测试进程兜底。

先分清是哪一种预算失控

Go 官方文档把 fuzzing 描述为持续变异输入并根据覆盖率寻找新路径的测试方式。go test -fuzz 默认可以持续运行，因此第一步是确认你要限制的是 fuzz 阶段本身，还是测试进程的整体生命周期。

用 -fuzztime 给 fuzz 阶段设总预算

-fuzztime 接受时间长度，也可以使用带 x 的迭代次数形式。它只回答“允许 fuzz 目标探索多久或多少次”，并不表示每个输入都必须在这段时间内完成。

# 给 FuzzDecode 运行 30 秒；到达预算且没有失败时正常结束
go test -fuzz=FuzzDecode -fuzztime=30s ./...

# 也可以按 fuzz 目标执行次数设置预算
go test -fuzz=FuzzDecode -fuzztime=1000x ./...

本地修改代码时可以从 10s 或 30s 开始，先确认种子语料和目标函数都能工作；CI 中则应把这个值写进脚本，让一次构建的耗时可预测。没有 -fuzztime 时，不要把“命令还没结束”误判成工具卡死。

把失败样本最小化与总预算分开

fuzz 找到失败输入后，工具通常还要尝试把输入缩小到更容易复现的样子。-fuzzminimizetime 控制的是每次最小化尝试的时间或迭代次数，不是正常探索阶段的总时长。

# 探索 60 秒；失败输入的单次最小化最多尝试 5 秒
go test -fuzz=FuzzDecode -fuzztime=60s -fuzzminimizetime=5s ./...

如果问题是“失败后迟迟没有结束”，先看最小化预算；如果问题是“没有失败但一直不结束”，应该调整 -fuzztime。在 CI 里可以给最小化更短的预算，但不能把它当成发现问题的替代品。

用 -parallel 和 -timeout 控制并发与兜底

fuzz 阶段的 -parallel 决定最多同时运行多少个 fuzz 子进程，默认值与 GOMAXPROCS 有关。把它调得很大不一定更快，目标函数如果占内存较多，反而可能让机器频繁争抢 CPU 或内存。

# 在资源有限的 CI 机器上限制并发，并为整个测试进程设兜底
go test -fuzz=FuzzDecode -fuzztime=2m -parallel=2 -timeout=3m ./...

这里的 -timeout=3m 是测试进程级 watchdog，它覆盖普通测试、种子语料执行以及 fuzz 阶段；它和 -fuzztime=2m 的职责不同。若 fuzz 阶段已经设置了 2 分钟，总超时可以略大一些，给编译、普通测试和收尾留出空间。

在 Fuzz 目标内限制单个输入

命令行参数解决的是整轮任务的资源预算，不能替代对单个输入的边界设计。比如解析器只需要验证有限大小的消息，就可以在 Fuzz 目标里跳过明显超出业务范围的输入。这样既避免一次调用占用过多内存，也把“本任务不覆盖什么”写在代码旁边。

func FuzzDecode(f *testing.F) {
    // 种子语料用于覆盖一个正常的 JSON 输入形态。
    f.Add([]byte(`{"name":"go"}`))

    f.Fuzz(func(t *testing.T, data []byte) {
        // 只测试业务允许的消息大小，避免超大输入拖慢单次调用。
        if len(data) > 1

输入过滤要和业务边界一致，不能为了让 fuzz 看起来更快而随意丢掉可能触发真实问题的输入。若目标函数本身存在无限循环或单个输入就能耗尽资源，仍然需要修复目标或被测代码；-timeout 只能负责把整体测试拉回可控状态。

三种场景怎么组合参数

本地快速反馈：使用 -fuzztime=10s，并发保持默认或设为较小值，目标是尽快知道种子语料和基本变异是否正常。

持续集成：使用固定的 -fuzztime、-parallel=2 和略大的 -timeout，让不同构建的耗时比较稳定；失败样本最小化预算可按机器性能下调。

专门的深度 fuzz：把 -fuzztime 调大，把 -parallel 与机器资源匹配，并保留失败样本与种子语料，避免把一次长时间探索变成不可复现的临时命令。

可以把最终命令写成项目脚本，例如：

# CI 预算示例：探索、最小化、并发和整体超时各自负责一件事
go test -fuzz=FuzzDecode \
  -fuzztime=90s \
  -fuzzminimizetime=10s \
  -parallel=2 \
  -timeout=2m ./...

常见问题

为什么设置了 -timeout，fuzz 还是运行很久？ -timeout 是整个测试进程的兜底时间，不是 fuzz 阶段的探索预算。要让无失败的 fuzz 主动结束，应设置 -fuzztime。

-parallel 越大是不是一定越快？ 不是。它增加并发 fuzz 子进程数量，目标函数消耗 CPU 或内存时，过高的值可能降低整体吞吐；先按 CI 机器的资源设置较小值，再根据实际任务调整。

可以只靠 t.Skip 限制 fuzz 时间吗？ 不可以。t.Skip 适合过滤单个输入的业务边界，不能替代 -fuzztime 对整轮探索设置预算。

归纳起来，Go fuzz 运行过长通常不是一个参数的问题：-fuzztime 管总探索，-fuzzminimizetime 管失败样本压缩，-parallel 管并发资源，-timeout 管整个测试进程，而输入大小边界应该放回 Fuzz 目标本身。把五个边界分开，命令就更容易复用，CI 也更容易稳定。