Go模糊测试是覆盖率引导的随机输入测试技术，用于发现panic、崩溃等异常行为；它不验证预期输出，而是自动构造海量输入探索边界路径，无法替代有业务语义的单元测试，仅作为健壮性兜底手段。
什么是 Go 的模糊测试，它和单元测试有什么区别
Go 1.18 引入的模糊测试（fuzzing）不是用来验证“正确输入是否得到预期输出”，而是主动探索函数在随机字节流输入下的行为——比如是否 panic、死循环、越界访问或逻辑崩溃。它底层用的是 coverage-guided fuzzing，会根据执行路径反馈不断变异输入，试图触发异常分支。
和 go test -run 不同，模糊测试不依赖你预设的测试用例，而是让 Go 运行时自动构造成千上万种输入；但这也意味着：它无法替代有业务语义的单元测试，只能作为健壮性兜底手段。
怎么写一个可 fuzz 的函数入口
模糊测试必须从一个签名严格为 func(F *testing.F) 的函数开始，且该函数内部必须调用 F.Add 提供种子输入，并用 F.Fuzz 注册被测函数。被测函数本身参数类型必须是基础类型或可序列化结构（如 []byte、string、int、struct{ X int; Y string }），不能含指针、channel、func 等不可序列化类型。
常见错误现象：fuzz: cannot encode value of type *bytes.Buffer 或 fuzz: function under test must take only supported types。
立即学习“go语言免费学习笔记（深入）”；
- 被测函数若接收
io.Reader，需先转成[]byte再传入，或重写接口为接受[]byte - 避免在
F.Fuzz回调里做全局状态修改（如改包级变量），否则会导致多次 fuzz 执行互相污染 - 如果函数有外部依赖（如 HTTP client、文件读取），必须 mock 或提取为参数，否则 fuzz 会卡在阻塞调用上
示例：对 JSON 解析做模糊测试
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func FuzzParseJSON(f *testing.F) {
f.Add([]byte(`{"name":"alice","age":30}`))
f.Fuzz(func(t *testing.T, data []byte) {
var v map[string]interface{}
if err := json.Unmarshal(data, &v); err != nil {
// 非 fatal 错误，允许解析失败
return
}
// 这里可加轻量级逻辑校验，比如 key 数量不能超 100
if len(v) > 100 {
t.Fatal("too many keys")
}
})
}
如何运行并解读模糊测试结果
执行 go test -fuzz=FuzzParseJSON -fuzztime=30s 即可启动。默认 fuzz 会持续运行直到超时或被中断；首次运行还会生成 fuzz/corpus 目录存放有效种子。
关键信号：
- 发现 crash 时，Go 会输出类似
panic: runtime error: index out of range [x] with length y的错误，并把触发该 panic 的最小化输入保存到fuzz/corpus/xxx文件中 - 若提示
fuzz: elapsed: 30s, execs: 124567 (4152/sec), newinputs: 3 (0/sec), crashes: 1，说明已找到一个可复现的崩溃点 - 注意：crash 输入是二进制字节流，用
cat fuzz/corpus/xxx | xxd -p -c 16查看原始内容，别直接用cat打印，可能含控制字符
性能影响：模糊测试默认启用 coverage 分析，会轻微拖慢执行速度，但这是必要开销；禁用（-fuzzminimize=false）只会让问题更难定位，不建议。
哪些函数适合加模糊测试，哪些其实没必要
模糊测试真正有价值的地方，在于处理**不受信输入**的边界场景：序列化/反序列化、协议解析（HTTP header、DNS packet）、正则匹配、压缩解压、密码学编码（base64、hex）、文本解析（CSV、INI、TOML）。这些函数一旦遇到畸形输入就容易崩，而人工很难穷举所有组合。
但以下情况基本不用 fuzz：
- 纯计算函数（如
Max(int, int)），输入域小且确定，单元测试全覆盖更高效 - 带强前置校验的函数（如先用
regexp.MatchString检查格式再处理），fuzz 很难突破校验层，收益极低 - 严重依赖外部状态的函数（如操作数据库事务），fuzz 无法提供稳定环境，反而掩盖真实问题
一个容易被忽略的点：模糊测试不会自动帮你修复 bug，它只暴露“这里会崩”。你得用 corpus 里的输入去复现、调试、加 guard、再跑一遍确认 crash 消失——这个闭环才是关键。
