Go原生fuzzing应从首个测试起并行启动，它通过生成极端输入（如nil、超长JSON、截断UTF-8）暴露边界认知盲区；需用f.Add()提供有效种子、避免I/O和日志、合理使用-fuzztime与-fuzzminimizetime。
Go 原生 fuzzing（go test -fuzz）不是“学完语法再补的安全课”，而是从第一个 func TestXxx 就该并行启动的编码习惯——它直接暴露你对输入边界的认知盲区。
为什么 go test -fuzz 比手写测试更容易发现空指针和越界访问
因为 fuzz 引擎会持续生成你根本不会手动构造的输入：全零字节、超长嵌套 JSON、含 \x00 的 UTF-8 截断字符串、长度刚好触发 slice 扩容临界点的 []byte。这些输入在单元测试里常被忽略，但 runtime 一碰到就 panic。
-
strings.Index遇到 nil 字符串直接 panic，而 fuzz 会传nil进去 - JSON 解析器对
{}和{}后多一个\x00行为可能完全不同 - 自定义
UnmarshalJSON方法若没检查len(data) == 0，fuzz 会立刻触发 index out of range
fuzz.F.Add() 不是可选步骤，是控制变异方向的开关
不调用 f.Add()，fuzz 就只能从空输入开始随机变异，效率极低；加了合适的种子，变异器才能聚焦在你关心的结构上。比如解析 Markdown 表格，只加 f.Add("a|b|c\n-|-|-\nd|e|f")，比加一百个纯字母字符串更可能触发列对齐逻辑缺陷。
- 种子必须覆盖三类场景：
"{}"（合法最小）、"{"（截断）、"{" + strings.Repeat("a", 1024)（超长） - 避免加纯随机大文件（如 10MB 二进制），会导致初始语料库膨胀、变异变慢
- 种子路径必须是
testdata/fuzz/FuzzParse/下的真实文件，不能是内存中生成的临时数据
别在 f.Fuzz() 回调里做耗时操作或外部依赖
fuzz 进程默认每个测试用例只有 1 秒超时，且运行在隔离 goroutine 中。如果你在里面发起 HTTP 请求、读取本地大文件或 sleep(100 * time.Millisecond)，要么被强制终止，要么拖慢整体变异速度，错过真正有价值的崩溃路径。
立即学习“go语言免费学习笔记（深入）”；
- 所有 I/O 必须 mock：用
bytes.NewReader替代os.Open，用httptest.Server替代真实 API 调用 - 禁止在回调中打印日志（
fmt.Println）——会污染崩溃堆栈，且降低执行速度 - 如果函数本身依赖全局状态（如
sync.Map），需在每次回调开头重置，否则变异结果不可复现
-fuzztime 和 -fuzzminimizetime 是调试关键，不是跑得越久越好
盲目设 -fuzztime=1h 不等于发现更多漏洞。go fuzz 的核心价值在于快速定位可复现的最小输入，而不是暴力穷举。实际调试时，应先用短时间定位 crash，再用 -fuzzminimizetime 自动精简输入。
- 首次运行建议：
go test -fuzz=FuzzParse -fuzztime=30s - 拿到 crash 输入后，立即用
go test -fuzz=FuzzParse -fuzzminimizetime=5s缩减到最小子串 - 注意：精简后的输入可能失去原始语义（如 JSON 变成非法片段），但它能稳定触发 panic，这才是调试需要的
真正容易被忽略的是：fuzz 发现的 panic 往往不是 bug 本身，而是你代码里早该处理却一直假设“输入不会这样”的防御缺口——比如忘了检查 len(b) >= 4 就直接取 b[3]，或者把 io.ReadFull 的错误当成了 EOF 而非意外中断。
