Go testing.F怎样为模糊测试添加稳定种子怎样在批处理代码中减少额外分配

为 testing.F 添加稳定种子，应在 f.Fuzz 之前用 f.Add 登记固定、可解释的边界输入，并让每条种子的参数类型与目标函数完全一致。批处理代码减少额外分配则要改动被测算法，例如直接遍历字节而不先分割出全部行；固定种子本身不会让业务代码自动减少分配。

官方文档：https://pkg.go.dev/testing

模糊测试指南：https://go.dev/doc/security/fuzz/

问题：种子稳定和低分配是同一件事吗

给批量文本处理函数补测试时，我会先把两个目标拆开：一个是同样的输入总能得到同样的结果，另一个是避免业务算法为每行构造临时对象。前者让失败容易重现，后者需要观察实际实现与基准数据。这是设计取舍，并非本文已经运行性能测试的结论。

稳定种子不等于要求模糊引擎每次生成相同输入序列。引擎会基于语料探索，调用顺序也不应被业务逻辑依赖。真正需要固定的是输入合同、性质判断和目标函数的外部依赖：同一输入不依赖当前时间、网络内容或上一次调用留下的状态。

最小配方：固定输入类别与明确性质

本例定义一个很窄的合同：只以 LF 字节分隔记录，统计字节长度大于零的行；CR 不作特殊剥离，空格也算内容。这样遇到任意字节时都有明确结果，而不是把“文本行”当成含糊约定。空输入、单独 LF、无尾换行、带尾换行、连续空行和非文本字节构成六类种子。

语料输入组包含固定种子、f.Add 和模糊输入；性质检查组包含目标回调、被测计数器和参考计数器。固定种子由 f.Add 登记，种子和模糊输入都供目标回调使用，回调分别依赖被测计数器和参考计数器。这些是静态依赖，不是运行顺序图。

f.Add 的参数个数、类型、顺序必须与 f.Fuzz 回调中 *testing.T 后面的输入一致。本文使用 []byte，所以每次添加一份 []byte，而不是有时用 string、有时用 []byte。每个 FuzzXxx 只调用一次 f.Fuzz；参数不支持任意自定义结构体，可以用受支持的基础类型组合表达。

关键代码：逐行扫描而不创建切片集合

把完整片段保存为 count_test.go，置于已有 Go 模块的包目录。这里把小型被测函数和 fuzz 入口放在同一文件便于阅读；实际项目可以把函数移入普通源文件，保留测试入口。Go 原生模糊测试从 Go 1.18 开始支持。

package batch

import "testing"

// countNonEmpty 只统计由 LF 分隔的非空行，不创建逐行字符串或切片集合。
func countNonEmpty(data []byte) int {
    count, start := 0, 0
    for i, c := range data {
        if c != '\n' {
            continue
        }
        if i > start {
            count++
        }
        start = i + 1
    }
    if start 

被测函数只记录 start 和 count，不创建每行子切片的集合，也不把字节转成字符串。参考实现改用“是否处于行首”的状态判断，避免逐字照搬被测逻辑。两者仍可能共享对业务合同的误解，因此种子类别必须能由人工解释：例如单独 LF 的非空行数应为零，a 后接 LF 的非空行数应为一。这些是合同推导，不是本机运行回执。

函数没有业务层显式堆对象构造，但不能据此宣称整个 fuzz 测试零分配。种子登记、引擎、失败格式化和测试框架有自己的开销；fuzz 每秒执行次数也不能替代批处理函数的分配基准。

变体：语料文件与批次复用

若稳定样本来自历史故障，可以将对应语料文件放入 testdata/fuzz/FuzzCountNonEmpty。文件名中的目标函数名必须匹配；语料文件使用 Go fuzz corpus 格式，不是把任意原始日志直接丢进去。避免放入账号、令牌或私人数据；保留故障结构即可。

普通 go test 会运行种子语料；启用探索则使用 -fuzz 参数。读者可在自己的包目录使用下面两条命令，本文不执行它们，也不声称已经发现或修复某个运行失败。

# 只运行这个模糊目标已有的种子语料，不启动持续探索。
go test -run='^FuzzCountNonEmpty$'
# 在当前包探索指定目标，运行时间限制为二十秒。
go test -run='^$' -fuzz='^FuzzCountNonEmpty$' -fuzztime=20s

如果真实算法需要临时工作区，可以在每次回调内创建并复用本次调用的缓冲，或让批处理函数接收由本次任务独占的 scratch。不要为省分配而让所有 fuzz 调用共用可变全局缓冲。状态跨调用遗留会破坏可重复性，也可能在并发场景造成数据竞争。

输入存储组包含输入字节和局部工作区；业务运算组包含逐字节扫描和行数结果；测量边界组包含 fuzz 框架和业务基准。逐字节扫描读取输入字节，使用局部工作区表达临时状态并产生行数结果；fuzz 框架调用业务运算，而业务基准用于单独衡量业务成本。

兼容边界与常见问题

种子越多越好吗？

优先保留能解释不同边界的样本。大量相似输入增加维护成本，也可能增加基础语料运行时间；不要用随机生成的一大堆种子替代清晰性质。

输入不符合业务格式时可以 Skip 吗？

可以按合同跳过确实不适用的输入，但过度过滤会让引擎难以触达有价值路径。本例对所有字节都定义结果，因此无需 Skip。

是否应该缓存上次计算结果？

通常不应该把跨调用缓存加入 fuzz 目标来提高表面速度。目标应该独立、确定且尽量快速；如果要研究业务缓存本身，应明确它的初始化和重置合同，再另设对应性质。