Go fuzz 失败语料放入 testdata 后怎样自动回归

可以。Go fuzz 找到失败输入后，会把它写成 testdata/fuzz/FuzzXxx 目录中的语料文件；修复代码后把这个文件和测试一起提交，日常执行普通 go test 就会自动重放它。-fuzz 用来继续探索新输入，不是每次回归都必须开启的模式。

官方文档：https://go.dev/doc/security/fuzz/

先搭一个能留下失败样本的小项目

把 fuzz 目标和语料目录放在同一个 Go 包里，最容易让代码、失败输入和回归命令一起演进。下面用一个接收 JSON 字节的解析函数作示例，重点不在解析业务，而在语料的生命周期。

fuzz-regression/
├── parser.go
├── parser_fuzz_test.go
└── testdata/
    └── fuzz/
        └── FuzzParse/

目录名中的 FuzzParse 必须和 fuzz 函数名对应。Go 的种子语料可以来自测试代码中的 f.Add，也可以来自 testdata/fuzz/FuzzParse 文件；两者会被同一个 fuzz 目标使用。

写出稳定的 FuzzXxx 入口

先给目标放几条小而有效的初始样本。下面的代码只是可保存的示例，文中的输出和失败语料均不表示已经在本文执行。

package parser

import (
    "encoding/json"
    "testing"
)

func ParseConfig(data []byte) (map[string]any, error) {
    var cfg map[string]any
    // 让解析错误返回给调用方，避免把坏输入误当成空配置。
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, err
    }
    return cfg, nil
}

func FuzzParse(f *testing.F) {
    // 这些样本帮助 fuzz 从合法对象、空输入两条路径开始探索。
    f.Add([]byte(\`{"mode":"safe"}\`))
    f.Add([]byte(\`{}\`))
    f.Add([]byte{})

    f.Fuzz(func(t *testing.T, data []byte) {
        // fuzz 目标只检查函数是否能安全处理任意字节。
        _, _ = ParseConfig(data)
    })
}

f.Add 的参数类型必须和 f.Fuzz 回调的参数类型一致；这里都是 []byte。它们是代码内种子，不等于已经发现的失败语料。

把失败文件作为回归资产提交

当 fuzz 目标真的失败时，Go 会在对应的 testdata/fuzz/FuzzParse 目录写入一个语料文件，并给出可定位该样本的测试名和哈希。不要只把终端日志里的可读输入复制到注释或普通测试表中；应保留 Go 生成的完整语料文件。

语料文件通常以类似下面的格式保存。第一行是编码版本，后面的每一行按 fuzz 回调参数顺序记录一个值。

go test fuzz v1
[]byte("...")

这里的省略号只是文章中的占位展示，真实文件应由 Go fuzz 引擎生成。语料文件可能包含转义字节或多个参数，不能手工改成看起来更短的字符串。提交前只需要确认它位于正确的 testdata/fuzz/FuzzParse 目录，并和源码一起进入版本控制。

如果仓库使用 Git，可以把目录视为测试资产检查：

# 查看失败语料是否和 fuzz 测试一起进入提交范围。
git status --short testdata/fuzz/FuzzParse parser_fuzz_test.go

# 只查看语料文件名，不把原始输入复制到日志或工单中。
git diff --stat -- testdata/fuzz/FuzzParse

语料中可能含有敏感业务数据。若输入来自真实请求，要先替换为等价的最小安全样本，再提交；不能因为要做回归就把凭据、个人信息或生产报文直接放进仓库。

普通 go test 会自动重放失败语料

这是“自动回归”的关键：不开启 fuzz 模式时，Go 仍会执行 f.Add 和 testdata/fuzz/FuzzParse 中的种子语料。修复前，失败文件会让测试继续失败；修复后，同一文件会成为防止回归的固定样本。

# 日常开发和 CI 默认重放全部种子语料。
go test ./...

# 只运行这个 fuzz 目标及其种子，缩小排查范围。
go test -run=FuzzParse

# 已知某个样本哈希时，只重放这一条语料。
go test -run='FuzzParse/'

第三条命令中的 要替换成 Go 输出的实际子测试名。它适合定位某一个失败样本，但提交到 CI 配置时通常保留第一条，让整套种子语料都参与回归。

用 go test -fuzz 继续寻找新样本

普通回归只重放已知种子；想继续发现新路径，再开启 fuzz 模式：

# 限制本轮探索时间，避免本地命令无限运行。
go test -fuzz=FuzzParse -fuzztime=30s

# 只在当前包中探索，并保留普通测试先行执行的默认行为。
go test -fuzz=FuzzParse -fuzztime=30s ./...

如果新输入导致失败，Go 会继续把它写到相同的 testdata/fuzz/FuzzParse 目录，并给出单条重放命令。修复后不要删除这个样本；把它最小化、去除敏感信息并提交，下一次普通 go test 就会覆盖这条回归路径。

模糊测试过程中产生的覆盖语料缓存与仓库中的种子语料不是一回事。日常回归依赖项目目录下的 testdata/fuzz；不要把本机缓存目录当成团队共享的回归资产。

从零项目到 CI 的分层执行

一个简单的分层方式是：每次提交执行普通测试，定时任务或专项任务再执行有限时长的 fuzz。这样既能快速发现已知问题，也不会让每次提交都承担长时间探索成本。

# 每次提交执行确定性的种子回归。
go test ./...

# 定时任务执行有上限的随机探索；失败语料仍要回到代码仓库审查。
go test -fuzz=FuzzParse -fuzztime=2m ./...

几个容易踩坑的边界

把文件放到 testdata 根目录可以吗？

不行。fuzz 语料需要放在包目录下的 testdata/fuzz/，测试名和目录名要对应；普通的 testdata/input.json 不会自动成为 fuzz 种子。

修复后应该删除失败语料吗？

通常不应该。它的价值正是把曾经触发过的缺陷固定下来。只有样本含敏感信息、超过仓库容量边界，或已经被更小且等价的样本替代时，才应按团队规则脱敏、最小化或合并。

所有失败输入都要手写成 f.Add 吗？

不需要。失败文件已经是种子语料，放入对应目录即可。f.Add 更适合少量稳定的基础样本；大量或不断增长的失败样本交给 testdata/fuzz 管理更清楚。

只跑 -fuzz 不跑普通 go test 可以吗？

不建议。-fuzz 解决的是继续探索，普通 go test 才是快速、确定地确认已有失败样本没有重新出现。两者应当分层，而不是互相替代。

最终可以记住一条工作链：fuzz 发现失败输入，Go 把它写入 testdata/fuzz/FuzzXxx，修复后提交该文件，日常 go test 自动重放，定时任务再用 -fuzztime 继续探索。这样失败语料才真正从一次性排错结果变成长期可维护的回归测试。

技术参考：https://go.dev/doc/tutorial/fuzz；https://go.dev/doc/security/fuzz/；https://pkg.go.dev/testing。