Go fuzz 测试持续扩大输入的资源控制

Go fuzz 测试“越跑越久”通常不是一个单独的超时故障：可能是没有给探索阶段设置 -fuzztime，也可能是单次 fuzz target 太慢、seed corpus 过大，或者失败后的最小化阶段又占用了额外时间。更麻烦的是，如果测试把文件、全局变量或外部服务状态留在每次调用之间，输入扩大后就会出现结果不稳定。处理顺序应当是先划分时间预算，再缩小语料，最后隔离副作用。

官方资料：https://go.dev/doc/security/fuzz/

影响面：为什么输入扩大后时间和结果一起失控

Go 的 fuzz 引擎会从 seed corpus 出发不断变异输入，并保留能扩展覆盖率的有趣输入。输入量增加本身不是问题，真正的风险在于每次调用都变慢，或调用之间互相污染：例如把 fuzz 输入追加到包级切片、重复写同一个临时文件、调用真实外部服务，都会让并行 worker 的执行时间和结果产生漂移。

先把故障拆成三条线：探索阶段是否没有结束条件；失败后最小化是否占用过久；同一输入在干净进程与连续调用之间是否得到不同结果。这样可以避免只把 -fuzztime 调小，却留下 target 本身的资源泄漏。

时间线：把探索预算和最小化预算分开

最容易复现的情况是直接运行 go test -fuzz=FuzzParser。如果没有失败，它可能一直运行；当某个输入触发失败后，引擎还会尝试把输入缩到更小、更容易复现的值。下面的命令把两段预算明确写出来：

# 探索最多 30 秒；失败输入的每次最小化尝试最多 10 秒
go test -run '^$' -fuzz '^FuzzParser$' -fuzztime 30s -fuzzminimizetime 10s

# 也可以用迭代次数控制探索，适合对执行速度差异较大的环境做粗粒度预算
go test -run '^$' -fuzz '^FuzzParser$' -fuzztime 20000x

-run '^$' 的作用是跳过其他普通测试，让这次排查只关注目标 fuzz 测试；它不是线上运行参数。-fuzztime 可以接受时长或 Nx 迭代次数，-fuzzminimizetime 也有类似形式。预算到期时是正常结束条件，不代表已经覆盖所有输入。

触发条件：seed corpus 大而慢，target 还带着副作用

seed corpus 的职责是提供有价值的起点，不是把历史样本全部塞进测试。优先保留能进入不同解析分支、边界长度和错误路径的少量输入；失败输入被写入 testdata/fuzz/FuzzParser 后，会在普通 go test 中作为回归样例执行，因此要把它当作代码资产管理。

target 内部应当每次调用都建立独立状态，尤其不要保留 fuzz 引擎传入的可变字节切片，也不要把请求写入固定路径后再依赖上一次文件内容。外部 HTTP、数据库和随机数依赖应替换为内存实现或显式固定的测试替身。下面的示例只展示“复制输入并返回结果”的边界：

func FuzzDecode(f *testing.F) {
    // 种子覆盖空输入、普通输入和协议边界，避免无差别堆积样本。
    f.Add([]byte(""))
    f.Add([]byte("name=value"))
    f.Add([]byte{0x00, 0xff})

    f.Fuzz(func(t *testing.T, input []byte) {
        // 不保留 input 的底层数组，避免后续并行调用改写已保存的数据。
        isolated := append([]byte(nil), input...)
        if err := decodeForTest(isolated); err != nil {
            // 失败交给 testing.T，Go fuzz 会尝试保存并最小化触发输入。
            t.Skipf("当前样本不是目标格式：%v", err)
        }
    })
}

这里的 decodeForTest 代表被测解析函数，示例不宣称在本文环境中执行。若失败条件是业务不变量，应使用 t.Error 或 t.Fatal，不要用 Skip 把真正的缺陷吞掉；只有明确“不属于该输入格式”的样本才适合跳过。

根因：把一次调用当成了可持续共享的工作线程

Go 官方文档建议 fuzz target 快速且确定，并且行为不依赖全局状态。实际排查时可以按下面的顺序收敛：先单独运行 seed corpus，确认基础样本不会写共享目录；再把 -fuzztime 设成短时长观察单次吞吐；如果失败，单独重放失败样本；最后才调整最小化预算。

防复发：让失败输入成为可控的回归资产

发现失败后，先使用输出中的测试名和样本标识重放，再修复被测代码。修复后用普通 go test 确认已有 seed corpus 能稳定通过；在 CI 中给 fuzz 阶段设置明确预算，不要依赖开发机上的无限运行。对需要访问文件或外部资源的 target，用 t.TempDir() 创建每次测试自己的目录，并在调用结束前释放资源。

最小化后的输入不一定代表“最小业务案例”，它只是当前失败条件下更紧凑、便于复现的样本。保留它的同时，最好补一个人能读懂的注释或回归测试说明，记录它覆盖的边界。这样下一次扩大语料时，测试资产不会再次变成不可解释的文件堆。

常见问题

只设置 -fuzztime 就能解决 fuzz 超时吗？

不一定。它只限制探索阶段；如果单次 target 过慢、发生死循环或存在共享状态，仍然需要修复 target 的执行成本和隔离方式。

-fuzzminimizetime 0 是否应该长期使用？

它可以关闭最小化，但会牺牲失败样本的可读性和复现便利。更适合临时定位资源问题，长期 CI 通常应保留一个有限但可接受的最小化预算。