Go模糊测试（go test -fuzz）自1.18原生支持，独立于单元测试，需FuzzXxx函数和-fuzz参数触发，专注发现崩溃/panic；属性测试无官方支持，依赖gopter等第三方库，侧重逻辑不变式验证。
模糊测试（fuzzing）在 Go 里是 go test -fuzz，不是单元测试的延伸
Go 的模糊测试从 1.18 开始原生支持，但它和 go test 跑的普通测试完全隔离：不共享 TestXxx 函数，不走 -run 流程，甚至不默认编译进测试二进制。它专为发现崩溃、panic、死循环这类非预期行为设计，不是用来验证“输出是否等于预期”的。
- 必须用
func FuzzXxx(f *testing.F)声明，且函数名以Fuzz开头 -
go test -fuzz=.才会触发模糊执行；漏掉-fuzz参数，FuzzXxx函数会被直接忽略 - 初始语料（seed corpus）要放在
f.Add()里，否则模糊器可能卡在空输入上半天没反应 - 不支持
subtest，也不能在FuzzXxx里调用t.Fatal—— 只能用f.Fatal或让程序自己 panic
属性测试（property-based testing）在 Go 里没有官方支持，得靠第三方库
Go 标准库压根没提供类似 QuickCheck 或 Hypothesis 那种“生成任意符合约束的数据 + 断言不变式”的能力。go test 的 *testing.T 只负责控制流和失败报告，不负责数据生成或收缩（shrinking）。
- 主流选择是
github.com/leanovate/gopter，但它的 API 和写法跟标准测试割裂感强，比如要显式定义Gen、写Prop.ForAll，还要手动处理种子和最大尝试次数 - 你不能把
gopter.Prop直接塞进TestXxx里就跑通——它需要自己的 runner，通常得另起func TestXxx(t *testing.T)包一层 -
gopter 默认不记录失败用例，出错后想复现？得自己开
WithSeed固定随机源，否则下次运行很可能过不了 - 性能敏感场景慎用：gopter 默认每条 property 尝试 100 次，而一次
Gen可能涉及多次分配和校验，比手写几个f.Add()慢一个数量级
go test -fuzz 会自动做输入收缩（shrinking），但只对 panic / crash 有效
当你跑模糊测试时触发了 panic，Go 的 fuzz driver 会尝试把原始崩溃输入逐步简化，直到找到最短的复现路径。这个过程对定位边界条件极有用，但有个关键限制：它只在检测到进程异常终止（exit status ≠ 0）、panic、timeout 或 data race 时才启动收缩。
- 如果函数只是返回错误值（比如
err != nil），哪怕你写了f.Fatal("bad input")，也不会触发收缩 —— 它被当成“正常失败”处理 - timeout 默认是 60 秒，可通过
-fuzztime调整；但太短容易误判，太长又拖慢 CI - 收缩后的最小输入不会自动保存到 seed corpus，得手动复制粘贴进
f.Add()，否则下次go test -fuzz还得重新挖一遍 - 注意
runtime/debug.SetTraceback("all")不会影响模糊器的 panic 捕获逻辑，但能让你在收缩后的 panic 日志里看到完整栈帧
别混淆“测试目标”：模糊测的是鲁棒性，属性测的是逻辑一致性
拿解析 JSON 字符串举例：json.Unmarshal 的模糊测试目标是“喂各种乱码进去，它别 panic、别死循环、别读越界”；而属性测试的目标更可能是“对任意合法 JSON 输入，Unmarshal 后再 Marshal，结果字符串应等价于原始输入（忽略空格）”。前者防崩溃，后者保语义。
立即学习“go语言免费学习笔记（深入）”；
- 模糊测试适合 IO 边界、序列化/反序列化、parser、crypto 等易受恶意输入冲击的模块
- 属性测试更适合数学函数、编解码规则、状态机转换等有明确不变式（invariant）的逻辑
- 两者都难覆盖分支覆盖率 —— 模糊依赖随机变异，属性依赖生成器质量；真要测覆盖率，还是得靠
go test -cover配合人工构造用例 - CI 中建议分开运行：
go test -fuzz=.单独作为 long-running job，而属性测试因不确定性和耗时，最好加-short或限定迭代次数
真正麻烦的从来不是选哪个工具，而是想清楚你要防御什么问题：是怕用户传个超长 UTF-8 字符串导致栈溢出，还是怕自己写的哈希函数在某种分布下碰撞率超标。问题没界定清楚，工具再新也没用。
