Go testing.F.Skip 怎样跳过不适用的模糊测试输入

如果你想在 Go 模糊测试里跳过某一个不适用的输入，重点不是直接调用 f.Skip，而是看你手里的对象是谁：*testing.F 代表整个 fuzz 测试，f.Skip 会让整个测试跳过；进入 f.Fuzz 回调后，当前输入由回调参数 *testing.T 管理，此时应调用 t.Skip。这样既不会把“输入不在测试契约内”误报成失败，也不会把真正的断言问题吞掉。

一句话记忆：f.Skip 处理“这组 fuzz 测试现在不运行”，t.Skip 处理“这一份输入不值得继续断言”。如果输入属于测试契约却让结果不正确，就应该让测试失败。

先分清 f.Skip 和 t.Skip 的作用范围

模糊测试入口通常是一个接收 *testing.F 的函数。f.Fuzz 注册回调后，Go 测试框架会用不同输入多次调用这段回调；回调收到的第一个参数是 *testing.T，它代表当前这一轮输入。两个对象都提供了 Skip 方法，但控制层级完全不同。

官方 testing 文档还规定，F.Fuzz 通常只能注册一次；如果整个 fuzz 测试需要跳过，应在调用 f.Fuzz 之前处理。把 f.Skip 塞进回调，既不能表达“只跳过当前输入”，也容易让阅读者误解测试边界。

在回调中用 t.Skip 跳过不适用输入

假设被测解码器只接受非空、结构完整的二进制消息。模糊测试会主动生成大量边界字节，其中一部分可能只是“格式不属于本函数的输入契约”，并不是实现缺陷。此时可以在回调里先做输入分类，再调用 t.Skip。

package parser_test

import "testing"

func FuzzDecodeMessage(f *testing.F) {
	// Fuzz 只负责登记一次回调；每份输入的判断放到回调内部。
	f.Fuzz(func(t *testing.T, raw []byte) {
		// 空输入不属于本示例的消息契约，跳过当前输入即可。
		if len(raw) == 0 {
			t.Skip("empty message is outside the input contract")
		}

		message, err := decodeMessage(raw)
		if err != nil {
			// 格式无法解析时不继续做业务断言，避免把无效输入当成实现失败。
			t.Skip("invalid message encoding")
		}

		// 能解析的消息属于有效输入；这里失败就应该暴露实现问题。
		if err := checkRoundTrip(message); err != nil {
			t.Fatalf("round trip failed: %v", err)
		}
	})
}

这里的关键是“跳过当前调用”。t.Skip 会记录当前输入被跳过，并结束这次回调；其他输入仍然可以继续进入 fuzz 测试。它不是普通的 return 的文字替代：Skip 会向测试框架留下明确的跳过状态，后续查看测试结果时能知道这条路径被有意排除。

不要用 Skip 掩盖有效输入的失败

判断是否跳过时，先问一个问题：这个输入是否满足被测函数的公开契约？如果答案是否定的，例如编码格式根本无法解析，那么 t.Skip 合理；如果答案是肯定的，但解码后的对象无法通过往返校验、字段约束或不变量检查，就应该让当前 fuzz 输入失败。

func FuzzNormalizePath(f *testing.F) {
	f.Fuzz(func(t *testing.T, raw string) {
		// 空路径在本示例中没有测试价值，明确跳过这一份输入。
		if raw == "" {
			t.Skip("empty path is not a supported case")
		}

		got := normalizePath(raw)
		// 非空路径属于测试契约；规范化结果不满足不变量时必须失败。
		if got == "" {
			t.Fatalf("non-empty input produced an empty normalized path")
		}
	})
}

一个常见误区是：看到某个输入触发错误，就把所有错误都改成 t.Skip。这样做会让 fuzz 测试只剩“能处理的输入”，却失去发现回归的能力。可以把错误分成两层：输入格式错误属于前置过滤；实现返回了不应出现的结果，则属于失败信号。

整个 fuzz 测试不可运行时才用 f.Skip

f.Skip 适合放在 f.Fuzz 之前，用来表达测试级别的前置条件。例如测试依赖某个平台能力，而当前运行环境不具备这个能力，此时跳过的是整个 fuzz 测试，而不是某一份随机输入。

func FuzzPlatformParser(f *testing.F) {
	// 平台能力不满足时，整个 fuzz 测试都没有意义。
	if !platformParserAvailable() {
		f.Skip("platform parser is unavailable")
	}

	f.Fuzz(func(t *testing.T, raw []byte) {
		// 到达这里说明测试级前置条件已满足，下面只判断当前输入。
		if len(raw) 

注意两个层级不要混在一起：平台能力缺失是测试整体不可运行，当前字节串太短是单个输入不适用，而解析器对有效字节串返回错误则是需要关注的失败。这样写，测试报告里的跳过数量和失败信息才有可解释性。

普通测试与持续 fuzz 怎么配合

Go 的 fuzz 测试既可以像普通测试一样运行，也可以使用 -fuzz 进入持续探索。无论采用哪种方式，Skip 的语义都不变：f.Skip 仍然是整个 fuzz 测试级别，t.Skip 仍然是当前输入级别。

# 先按普通测试方式运行，快速确认测试入口和固定逻辑可用。
go test ./...

# 再限定一个 fuzz 目标和探索时长，避免示例命令无限运行。
go test -fuzz=FuzzDecodeMessage -fuzztime=30s ./...

持续 fuzz 时输入来自框架的变异探索，输入顺序和并行执行不应成为测试逻辑的一部分。回调里只根据当前输入做确定性的契约判断，既方便复现，也能避免把全局状态误当成 Skip 的替代方案。

排查 Skip 不生效时看这四点

1. 是否把 f.Skip 放进了回调。回调内部应使用 t.Skip；f.Skip 是 fuzz 测试整体控制。
2. 是否在 Skip 之后仍期待执行后续断言。Skip 会结束当前测试调用，后面的语句不会继续执行。
3. 是否把真实缺陷也标成跳过。有效输入导致的错误应由 Error、Fatal 或明确断言暴露。
4. 是否重复调用了 F.Fuzz。一个 fuzz 测试通常只注册一次回调；若需要整体跳过，要在注册前调用 f.Skip。

总结

“跳过不适用的模糊测试输入”真正要写的是回调参数 t.Skip，不是把 f.Skip 当成逐输入过滤器。前者跳过当前输入，后者跳过整个 fuzz 测试；对有效输入出现的错误则继续使用失败断言。只要先确定问题所在层级，再选择对应对象的方法，测试报告就能清楚地区分未覆盖、无效输入和真实回归。

常见问题

f.Skip 可以写在 f.Fuzz 回调里吗？

不建议这样表达逐输入跳过。回调里拿到的是 *testing.T，应使用 t.Skip；f.Skip 用于在注册回调前跳过整个 fuzz 测试。

t.Skip 和直接 return 有什么区别？

两者都会结束当前回调，但 t.Skip 会把这次执行记录为 skipped，并把意图传达给测试框架与读者；直接 return 只表示函数返回，不能说明这是有意排除的输入。

解析失败的随机输入都应该 t.Skip 吗？

只有当解析失败明确表示输入不在被测函数的契约内时才适合跳过。如果解析失败本身就是要发现的缺陷，就应该保留为失败，而不是隐藏。