Go模糊测试需用f.Add()显式注入已知失败用例，且必须在Fuzz函数开头以可序列化类型传入，否则模糊器无法复现；它不保存历史失败输入，f.Add()是唯一可靠锚定手段。
Go 模糊测试跑不出固定失败用例？先确认 f.Add() 是否真在跑
模糊测试（go test -fuzz）本身不保证复现历史失败，它只对当前输入空间做随机探索。如果你有个已知会 panic 的输入，但 go test -fuzz=FuzzParse 一直没触发它，大概率是 FuzzXxx 函数里漏了 f.Add() —— 模糊器根本不知道这个“坏输入”存在。
实操建议：
-
f.Add()必须在FuzzXxx函数体最开头调用，不能包在条件分支里，也不能被if testing.Short()拦住 - 传给
f.Add()的值必须是**可序列化的原始类型**：字符串、整数、字节切片等；不能传结构体指针或含闭包的函数 - 如果失败用例是二进制数据（比如一段损坏的 PNG），直接用
[]byte{0xff, 0xd9, 0x00}调用f.Add()，别试图从文件读再塞进去——模糊器不会帮你加载外部资源
回归测试用例怎么塞进模糊测试里不被忽略
模糊测试不是回归测试的替代品，但可以当“增强层”。把已知失败用例硬编码进 f.Add()，本质是让模糊器每次启动都先跑一遍这些“锚点输入”，避免它们在随机变异中被稀释掉。
常见错误现象：加了 f.Add("bad_input")，但 go test -fuzz=FuzzParse -fuzztime=1s 还是没报错。
立即学习“go语言免费学习笔记（深入）”；
原因和对策：
- 模糊器默认只 fuzz 第一个参数（
func FuzzParse(f *testing.F)中的f），你传的"bad_input"必须匹配FuzzParse签名里那个string或[]byte参数类型，否则会被静默丢弃 - 如果
FuzzParse接收多个参数（比如func FuzzParse(f *testing.F, s string, n int)），f.Add()就得传两个值：f.Add("bad", 42)，少一个就跳过 - Go 1.22+ 开始支持
f.SanitizeArgs，但别依赖它来“修正”类型——它只影响变异逻辑，不解决初始输入类型不匹配的问题
go test -fuzz 和 go test 并行跑时的竞态隐患
当你把回归用例同时放在普通测试（TestParseBadInput）和模糊测试（f.Add()）里，且两者共享全局状态（比如缓存 map、单例 logger），就可能在 go test ./... -race 下爆 data race。
性能与兼容性影响：
- 模糊测试默认启用
-race检测，而普通测试默认不启；同一包下混用，容易漏掉竞争点 - 如果回归用例依赖时间戳、随机数种子或临时文件路径，
f.Add()里的输入是静态的，但模糊器后续变异出来的输入可能撞上这些动态边界，导致失败模式漂移 - 建议：所有共享状态操作（如写日志、改全局变量）在
FuzzXxx中统一加锁，或改用sync.Map；普通回归测试保持无状态
为什么 go test -fuzz 找不到你修复过的 bug
模糊测试发现 bug 后，你修了代码、加了回归测试，但下次跑 go test -fuzz=FuzzXxx 却不再报错——这不代表问题消失，而是模糊器没再生成能触发旧漏洞路径的新输入。
关键点在于：
- 模糊器不保存“失败输入的历史快照”，它只记录最后一次崩溃的输入到
testdata/fuzz/；如果修复后你删了那个文件，它就彻底忘了 -
f.Add()是唯一可靠的“人工锚定”手段，但必须确保它传的值和原始失败输入**完全一致**（包括不可见字符、BOM、换行符） - 如果原始失败靠特定浮点精度误差触发，用
float64直接传可能因常量折叠丢失精度；换成math.Float64frombits(0x400921fb54442d18)更稳妥
真正容易被忽略的是：模糊测试的“覆盖目标”是代码路径，不是语义正确性。一个修复可能堵住某个 crash 路径，却引入新逻辑缺陷——这时候，f.Add() 塞进去的回归用例，是你唯一能守住的底线。
