Go fuzzing 外部依赖隔离与可重复运行

Go fuzzing 的可重复性，关键不在于让随机输入“看起来固定”，而在于让 fuzz target 每次调用面对同样可控的边界：种子输入可以重放，外部依赖可以替换，调用之间不共享可变状态，失败样本可以留下来继续跑。Go 官方文档也明确建议 fuzz target 足够快、确定，并且不要依赖共享状态。

本文用一个解析服务的例子说明这套结构。真实项目中的网络、时钟、随机数、文件系统和数据库，都应该在 fuzz target 外部收口；fuzz target 只负责准备输入并调用业务函数。

先把外部依赖放到可替换边界

最容易破坏可重复性的写法，是在 f.Fuzz 回调里直接访问真实网络、当前时间或共享数据库。一次输入失败后，下一次重放可能已经遇到不同的响应，读者很难判断是输入导致了问题，还是外部环境发生了变化。

可以先定义一个窄接口，把业务真正需要的能力写出来，再给 fuzz 使用的 Fake 实现。下面的例子只让业务函数依赖“读取配置”和“保存解析结果”，不让它知道底层是文件、数据库还是 HTTP。

// Dependency 提供解析服务真正需要的两个外部能力。
type Dependency interface {
    LoadConfig(key string) (string, error)
    SaveResult(key, value string) error
}

// FakeDependency 用内存状态替代网络或数据库，便于每次调用重新创建。
type FakeDependency struct {
    Config  map[string]string
    Results map[string]string
}

func (f *FakeDependency) LoadConfig(key string) (string, error) {
    value, ok := f.Config[key]
    if !ok {
        return "", fmt.Errorf("missing config: %s", key)
    }
    return value, nil
}

func (f *FakeDependency) SaveResult(key, value string) error {
    // 结果写入本次调用专属的 map，避免污染下一条 fuzz 输入。
    f.Results[key] = value
    return nil
}

让每次 fuzz 调用拥有独立状态

接口隔离之后，还要避免把可变对象放在包级变量里。F.Fuzz 可能并行调用目标函数，官方文档要求目标行为不依赖共享状态，而且不能保留或修改 fuzzing 引擎传入的可变输入。

因此，回调里应该先复制输入，再创建 Fake 时钟、内存仓库或其他测试依赖。业务函数可以修改副本，但不能修改引擎传入的底层字节数组。

// FuzzParse 验证解析结果在固定依赖下保持基本不变量。
func FuzzParse(f *testing.F) {
    // 这些种子用于普通 go test，也用于开始 fuzzing 前的基线覆盖。
    f.Add([]byte(`{"name":"demo","enabled":true}`))
    f.Add([]byte(`{"name":"","enabled":false}`))

    f.Fuzz(func(t *testing.T, input []byte) {
        // 复制输入，避免业务函数意外修改 fuzz 引擎持有的底层数组。
        isolated := append([]byte(nil), input...)
        dep := &FakeDependency{
            Config:  map[string]string{"mode": "test"},
            Results: make(map[string]string),
        }

        got, err := ParseAndSave(isolated, dep)
        if err != nil {
            // 非法输入是解析器允许拒绝的情况，不把它误报为测试失败。
            t.Skip()
        }
        if got.Name == "" {
            t.Fatalf("accepted result has empty name")
        }
        if len(dep.Results) != 1 {
            t.Fatalf("saved results = %d, want 1", len(dep.Results))
        }
    })
}

这里的重点不是 Fake 是否“像真实服务”，而是它的状态边界是否清楚：一条输入创建一组依赖，一次回调结束后自然丢弃。若业务确实需要模拟超时或重试，可以把这些结果作为 Fake 的字段配置，不要在 fuzz 回调里随机读取系统时间或共享计数器。

把可重复性拆成种子、状态和缓存三件事

Go fuzzing 有两类重要输入来源：代码中的 f.Add，以及包目录下 testdata/fuzz/ 的语料文件。两者都会在普通 go test 中运行；fuzzing 发现失败输入后，也会把它写入这个目录，修复后它就自然变成回归样本。

建议把这三层职责分开：

• 种子：保留最小、代表性强的输入，帮助快速进入关键分支。
• 状态：在回调内部创建 Fake 依赖和输入副本，不让上一条输入留下修改。
• 缓存：把失败语料纳入版本控制，作为修复后的默认回归用例。

不要把构建缓存里的 generated corpus 当成团队共享的回归资产。它服务于 fuzzing 过程；真正要长期复现的问题，应整理成清晰的 testdata 语料或更直接的单元测试。

区分普通测试、持续 fuzz 与失败复现

同一份 fuzz 测试可以对应三种不同目的。提交前先跑种子，确认固定输入和 Fake 依赖没有问题；需要探索新路径时再开启 fuzzing；出现失败后，优先用保存下来的语料复现，而不是马上把运行时间调大。

# 先跑所有固定种子，快速确认回归入口正常。
go test ./...

# 只跑一个 fuzz 测试的种子，避免被其他测试日志干扰。
go test -run=FuzzParse

# 在限定时间内探索新输入，时间也可以写成迭代次数。
go test -fuzz=FuzzParse -fuzztime=30s

# 让失败语料参与普通测试，确认修复没有破坏默认回归路径。
go test -run=FuzzParse

-parallel 可以调整 fuzzing 进程并行度，但它不能替代依赖隔离。如果目标函数依赖全局时钟、共享 map 或真实服务，降低并行度只能减少碰撞，不能让结果真正稳定。更可靠的判断是：同一份失败语料在干净进程中重复执行，是否仍然给出同一个业务结论。

常见误区与落地清单

最后可以用四个问题做检查：输入是否被复制？依赖是否能替换？回调是否创建独立状态？失败语料是否能在普通 go test 中自动运行？四项都能回答清楚，Go fuzzing 才真正从“随机试一试”变成可持续的回归测试。

相关问题

f.Add 和 testdata/fuzz 应该怎么选？

短小、稳定、便于阅读的基础样本适合写在 f.Add 中；较大或由 fuzzing 发现的失败样本适合放入 testdata/fuzz/，方便版本控制和后续复现。

为什么 Fake 依赖仍然会让 fuzz 结果不稳定？

Fake 也可能包含全局状态、随机返回或跨调用缓存。隔离的关键不是类型名叫 Fake，而是每次回调都能从明确的初始状态开始，并且对同一输入给出一致的结果。