go测试文件必须以_test.go结尾，testxxx函数需首字母大写且参数为testing.t，fuzzxxx函数同理但参数为testing.f；文件、函数名、签名任一不满足则go test静默忽略。
Go 的测试驱动开发（TDD）和模糊测试不需要额外框架，但文件名、函数签名、包结构和命令参数必须严格匹配规则，否则 go test 会静默跳过或报 “no fuzz tests to run” —— 这不是环境没装好，而是写法错了。
Test 函数和 Fuzz 函数的命名与位置必须同时满足三重约束
单元测试和模糊测试共享同一套文件识别机制，但各自有不可妥协的签名要求：
- 测试文件必须以
_test.go结尾，且与被测代码在同一目录、同一包名下；放在test/子目录或新建test包会被完全忽略 -
TestXxx函数必须首字母大写、参数为*testing.T，例如func TestReverse(t *testing.T)；testReverse或Testreverse都不被识别 -
FuzzXxx函数必须首字母大写、驼峰命名、参数为*testing.F，例如FuzzParseInput；fuzzParseInput或Fuzzparseinput均无效 - 一个
_test.go文件里可以共存多个TestXxx和FuzzXxx，但FuzzXxx内部只能调用一次f.Fuzz()，多调会 panic
go test -fuzz= 命令卡住或提示 no fuzz tests 的真实原因
常见现象是执行 go test -fuzz=FuzzParseInput -fuzztime=10s 后无输出、无错误、也无崩溃，只返回成功码。这不是命令没生效，而是模糊测试根本没被发现：
- 检查 Go 版本：
go version必须 ≥ 1.18；1.17 及更早版本不支持模糊测试，命令会被当作普通测试忽略 - 确认函数定义在
xxx_test.go中，而非main.go或普通.go文件里——哪怕只有一行package main的空测试文件也不行 -
-fuzz=后跟的名称必须与函数名完全一致，包括大小写，例如-fuzz=FuzzParseInput对应func FuzzParseInput，少一个字母都不匹配 - 如果项目含多个模块，确保在待测包目录下执行命令，而不是项目根目录；
go test ./... -fuzz=...可能漏掉未显式导入的子包
f.Add() 不是可选的，而是模糊测试收敛的前提
很多人删掉 f.Add()，指望 fuzzer 自己“撞”出有效输入。对结构化数据（如 JSON、URL、二进制协议），这几乎不可能：
-
f.Add()提供的种子类型必须与f.Fuzz()闭包参数完全一致：闭包是func(t *testing.T, data []byte)，就只能传[]byte，不能传string或io.Reader - 至少覆盖三类种子：
f.Add([]byte(`{"name":"alice"}`))（合法典型）、f.Add([]byte(`{"name":`))（缺右括号）、f.Add([]byte{0x00, 0xff})（控制字符/边界字节） - 没有种子时，fuzzer 初始变异集中在短字符串（如
"a"、"aa"），很难生成嵌套 JSON 或带校验和的帧头；加 3–5 个种子后，通常 2 秒内就能触发panic: runtime error: index out of range - 种子可放在
seed_inputs/目录中，用f.AddFile()加载，但路径必须相对于当前包目录，且文件需存在
编译与运行时容易被忽略的细节
模糊测试不是“跑起来就行”，几个关键点直接影响能否复现崩溃、是否浪费 CPU：
-
go test -fuzz=.会运行所有FuzzXxx函数，但-fuzztime是总时长，不是每个函数的时长；想单独测一个，必须写全名：-fuzz=FuzzDecodePacket - 崩溃复现依赖
testdata/fuzz/FuzzXxx/下自动生成的.fuzz文件；手动修改或删除它会导致go test -fuzz=找不到历史崩溃输入 - 若被测函数启动 goroutine 并 panic，主 goroutine 不中断，fuzzer 看不到；所有逻辑必须同步执行，或用
sync.WaitGroup+recover捕获后显式t.Fatal - 避免在
f.Fuzz()闭包里做耗时操作（如完整解码 + 校验）；先快速检查长度、括号平衡、magic bytes，再进主逻辑，否则每秒迭代数可能低于 10
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
