Go fuzz测试不接受反射构造的值，因其不可序列化、无法被引擎追踪变异；必须通过fuzz.Consume*或转为[]byte写入corpus目录才生效。
为什么 reflect 生成随机数据在 Fuzzing 中容易失效
Go 的 fuzz 测试不接受任意反射构造的值——它只认 fuzz.NewFromGoFuzz 或内置的 fuzz.Consume* 系列函数生成的输入。你用 reflect.New(t).Interface() 拼出来的 struct，哪怕字段全填了随机数，fuzzer 也根本不会把它当“种子”喂给测试函数，更不会基于它变异。本质是：fuzzing 需要可序列化、可逆向变异的字节流，而反射对象是运行时内存结构，无法被引擎追踪。
-
go test -fuzz启动后只从fuzz目录下的 seed corpus 或自动生成的bytes开始变异，和你的反射逻辑完全无关 - 手动反射构造的值无法参与 coverage-guided 变异，等于绕开了 fuzzing 最核心的能力
- 如果你真要用反射辅助生成初始种子（比如批量造 struct），必须最终转成
[]byte并写入fuzz/corpus/目录，否则不生效
FuzzMyFunc 函数里怎么安全用 reflect 处理未知类型
只有在 fuzz test 函数体内、且明确知道输入来自 f.Corpora 时，才能谨慎用反射做类型适配。典型场景是：你想 fuzz 一个泛型函数，但 Go 1.22+ 的 fuzz 还不支持直接传泛型参数，只能靠反射解包。
- 永远先检查
data长度是否足够，len(data) == 0是常见 panic 来源 - 别直接
reflect.ValueOf(data).Convert(...)——data是[]byte，不是目标类型的二进制表示；正确做法是用encoding/gob或json.Unmarshal解析（前提是你的类型支持） - 如果类型含
func、chan、unsafe.Pointer，反射解包必然失败，fuzzer 会跳过该输入并报panic: reflect: call of reflect.Value.Interface on zero Value - 示例片段（处理简单 struct）：
func FuzzMyFunc(f *testing.F) { f.Add([]byte(`{"Name":"test","Age":25}`)) f.Fuzz(func(t *testing.T, data []byte) { var u MyStruct if err := json.Unmarshal(data, &u); err != nil { return // 忽略解析失败的输入，fuzzer 会继续试别的 } // 此处可对 u 做反射检查字段值，但别试图用 reflect 修改后再传给被测函数 _ = myFunc(u) }) }
用 reflect 批量生成 seed corpus 时最常踩的三个坑
把反射当成“快速造测试数据工具”很自然，但写到 fuzz/corpus/ 里就容易翻车。关键不是“能不能造”，而是“造出来的能不能被 fuzz 引擎读进去”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 文件名必须是纯 ASCII，且不能带空格或特殊符号；
fuzz/corpus/user-输入_含中文.json会被静默忽略 - 内容必须是合法的、可完整反序列化的字节流；用
fmt.Sprintf拼 JSON 而不校验格式，会导致invalid character错误且无提示 - struct 字段若为指针或嵌套 slice，
json.Marshal后可能为空或 null，fuzzer 解析时默认值填充行为不可控，建议统一用非空零值初始化再 marshal - 推荐做法：写个独立工具，用
reflect.StructTag读取json:tag，调用json.Marshal输出，再用go run ./gen-corpus.go生成文件到fuzz/corpus/
什么时候该放弃 reflect，改用 fuzz.Consume*
当你发现需要处理的类型超过两层嵌套、含 interface{}、或字段数量动态变化时，反射路径的维护成本和不确定性已经远超收益。Go fuzz 内置的消费器虽然看起来“原始”，但稳定、可预测、与引擎深度协同。
立即学习“go语言免费学习笔记（深入）”；
-
f.ConsumeInt()返回int，不是int64，注意类型匹配；用错会 panic -
f.ConsumeString()默认长度上限是 128，想测超长输入得先f.Switch("long")配置，否则永远拿不到 >128 字符的字符串 - 嵌套 struct 推荐拆成多个
Consume*调用，而不是反射遍历字段——前者能被覆盖率反馈驱动变异，后者只是固定模板 - 真实例子：fuzz 一个 HTTP handler，直接用
f.ConsumeString()生成 path，f.ConsumeIntn(6)生成 status code，比反射解析整个 request struct 更快、更稳、更容易定位 crash 根因
真正难的不是怎么让反射跑起来，而是判断哪些地方它不该出现——尤其在 fuzzing 这种依赖确定性输入流的场景里，任何绕过 f 实例的“手工注入”，都在削弱 fuzz 引擎本身的价值。
