Go 模糊测试语料增长过快怎么办

Go fuzz 运行一段时间后，磁盘突然变满，通常不是 testdata/fuzz 里的种子语料失控，而是模糊测试为了扩大覆盖率写入了大量本地生成值。处理这类问题的关键不是直接删除所有文件，而是先分清“应该进版本库的样本”和“可以随任务清理的缓存”。

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

先分清种子语料、失败样本和生成语料

Go 的 fuzz 测试有三种容易混淆的数据。第一种是代码里的 f.Add 参数，第二种是 testdata/fuzz/FuzzX 目录中的语料文件，这两者都属于 seed corpus，普通执行 go test 时也会被测试。第三种是 fuzz 引擎为了探索新覆盖率而生成的值，它保存在构建缓存下的 fuzz 目录，主要服务于继续 fuzz，并不等于项目必须提交的测试样本。

遇到磁盘增长时，先看增长位置和用途：

失败输入要固化，普通生成值不要全量搬进仓库

当 fuzz 找到能触发错误或崩溃的输入时，Go 会把它写成该 fuzz 测试的语料文件。修复代码后，这个文件仍会在普通 go test 中执行，因此它的价值是把一次随机发现变成稳定回归边界。相反，仅仅因为某个输入扩大了覆盖率，并不意味着它值得全部提交；大量相似样本会增加评审、检出和测试成本。

func FuzzDecode(f *testing.F) {
    // 只放少量稳定的边界输入，避免把探索缓存当成源码资产。
    f.Add([]byte("{}"))
    f.Add([]byte("[1,2,3]"))

    f.Fuzz(func(t *testing.T, data []byte) {
        // 模糊目标应尽量确定、快速，便于失败输入重复执行。
        if err := Decode(data); err != nil {
            t.Skip()
        }
    })
}

如果一个失败文件能说明解析器、协议边界或安全修复，就保留并在提交说明中写清它覆盖的缺陷。若只是重复已有边界、体积很大且没有独立回归价值，可以在人工确认后不提交，但不要把“没提交”误解成“可以删除所有 seed corpus”。

把 fuzz 运行窗口和缓存目录分开管理

本地探索可以持续运行，但 CI 不应让每次任务都无限增长。先给 fuzz 一个明确时间窗口；没有发现失败时，任务到点退出，已有的种子和回归样本仍可由下一次普通测试执行。

# 限制一次 fuzz 任务的最长运行时间，避免 CI 无期限占用机器。
go test -run=^$ -fuzz=FuzzDecode -fuzztime=60s

# 任务结束后清理 Go 构建缓存中的 fuzz 生成值。
go clean -fuzzcache

-run=^$ 只是示例中的资源取舍：如果项目需要先运行普通测试，应删掉它，让其他测试照常执行。真正需要调整的是 -fuzztime 和 CI 缓存保留时间。并行度也会影响 CPU、内存和磁盘写入，先按默认值观察，再针对受限 runner 调低 -parallel，不要把“加并行”当成控制语料增长的办法。

CI 中用清单判断该留什么

把 fuzz 任务拆成两个边界：版本库只保存可复现的 seed corpus 和失败回归样本，CI 工作区保存本轮探索产生的缓存。若 CI 需要复用缓存，也给它设置短保留时间，并把缓存命中当作加速手段而不是正确性前提；缓存丢失后，测试仍应能从代码和已提交语料重新开始。

• 看到 testdata/fuzz/FuzzX 文件：先确认它是否对应一个已修复或必须守护的边界。
• 看到 $GOCACHE/fuzz 变大：优先清理 fuzz 缓存，避免误删源码目录。
• 看到 CI 反复积累：缩短缓存保留期，并让每个任务使用独立工作区。
• 看到样本巨大：先记录复现命令和类型边界，再决定是否压缩或拆分；不要只按文件大小盲删。

这样处理后，语料增长就从“磁盘异常”变成了可解释的数据生命周期：输入样本服务回归，生成缓存服务探索，清理动作只作用于后者。

相关问题

清理 fuzz 缓存会删除提交的失败样本吗？

不会。go clean -fuzzcache 针对的是构建缓存中的 fuzz 值；版本库里的 testdata/fuzz 文件仍由项目管理。

为什么普通 go test 也会执行失败输入？

因为失败输入已经成为该 fuzz 测试的 seed corpus，普通测试会用它检查修复是否持续有效。

所有扩大覆盖率的输入都要提交吗？

不需要。优先提交能复现缺陷、保护协议边界或代表独立业务约束的样本，其余生成值留在短生命周期缓存中。