Fuzz函数必须以Fuzz开头、接收*testing.F参数、置于_test.go同包文件中；f.Add()类型顺序须与f.Fuzz签名严格一致；仅支持基础类型组合；种子需覆盖边界值以加速变异。
怎么写一个能跑起来的 Fuzz 函数
Go 1.18 引入 fuzz 测试，2026 年仍沿用同一套核心机制——没所谓“新特性”，但实践更成熟了。关键不是追版本，而是写对签名、塞对种子、别踩类型雷。
-
Fuzz开头 +*testing.F参数是硬性要求，函数名必须像FuzzParseJSON，不能是fuzzParseJSON或TestFuzzParse - 必须放在
_test.go文件里，且和被测代码同包（否则go test -fuzz=...找不到） -
f.Add()的参数类型和顺序，必须和f.Fuzz(func(t *testing.T, x string, y int) { ... })里的参数完全一致——错一个类型或顺序，运行时报panic: seed values don't match fuzz function signature - 只支持基础类型及其组合：
string、[]byte、int64、float64、bool、struct{...}、[]int等；不支持map、func、带方法的自定义类型
种子（seed）不是摆设，是 fuzz 的加速器
很多人只加 f.Add("a") 和 f.Add("b")，结果 fuzz 跑 5 分钟还在试 "c"、"d"、"e"——这说明引擎根本没摸到边界。种子不是“示例”，是给变异引擎指路的地标。
- 数值类：必加极值三件套 ——
math.MaxInt64、math.MaxInt64-1、math.MaxInt64+1（即使溢出，fuzzer 会截断并尝试邻域） - 字符串类：空串
""、单字符"\x00"、超长串strings.Repeat("a", 1、含非法 UTF-8 的"\xff\xfe" - 结构体/切片：用字面量构造典型坏案例，比如
f.Add([]byte{0, 0, 0, 0})对应 IPv4 解析，f.Add(`{"name":null}`)针对 JSON 反序列化 - 别把单元测试用例全搬进来——fuzz 不需要 20 个合法 case，3～5 个有代表性的就够了；重点是“坏得有道理”
崩溃了，怎么快速定位是真 bug 还是误报
执行 go test -fuzz=FuzzXXX -fuzztime=30s 后看到 --- FAIL: FuzzXXX (0.00s) 并附 panic，别急着修——先看是不是自己写的验证逻辑太激进。
- fuzz 回调里禁止用
t.Fatal、t.Error；出错直接panic，否则会被忽略 - 常见误报来源：
json.Unmarshal遇到非法 UTF-8 默认返回 error，但如果代码里用了unsafe.String或跳过校验，就可能 panic——这不是 fuzz 错，是你的解析逻辑没兜住 - crash 用例自动存进
fuzz/corpus/（或fuzz/crashers/），文件内容是原始输入；用cat fuzz/corpus/00a7e1 | xxd看二进制，比盲猜靠谱得多 - 复现时加
-fuzzcachedir=.复用已有语料，避免每次从零开始；加-v可看到每轮执行的输入摘要
为什么跑半天没 crash？不是没 bug，是没喂对“食谱”
很多团队反馈“fuzz 跑了 10 分钟只发现 1 个空指针”，大概率是目标函数本身屏蔽了错误路径，或者验证太宽松。
立即学习“go语言免费学习笔记（深入）”；
- 被测函数如果内部
recover()了 panic，fuzz 就看不到——确保它不吞异常，或改用log.Panic强制暴露 - 只检查
err != nil不够，要验证错误语义：比如解析 IP 时返回"invalid port"但输入根本没冒号，就是漏校验 - round-trip 校验最有效：解析后再序列化，比对是否一致；失败就
panic，不依赖返回值 - 别在 fuzz 回调里做网络请求、读文件、访问数据库——状态不可控，fuzz 会卡死或误判
真正难的不是让 fuzz 跑起来，而是判断哪个 panic 值得深挖。2026 年大家已普遍用上覆盖率引导（-fuzzminimize 自动精简输入），但依然得靠人读懂 panic 时的 goroutine stack 和输入上下文——工具只是放大镜，不是诊断书。
