用testing.t.run是go中组织可并行、可独立失败、可清晰命名子测试的唯一标准方式；它提供独立生命周期、并发控制与层级命名，避免耦合、定位难及无法按名运行等问题。
直接说结论：用 testing.T.Run 是 Go 中组织可并行、可独立失败、可清晰命名的子测试的唯一标准方式；不这么写，测试就容易耦合、难定位、无法按名运行。
为什么必须用 Run 而不是普通函数调用
很多人把多个测试逻辑写在同一个 TestXxx 函数里，靠 if 或变量控制流程——这会导致：失败时只报 TestXxx 失败，看不出是哪个分支出问题；无法单独运行某条用例（比如 go test -run TestParse/invalid_json）；子测试间共享状态（如全局变量、缓存）引发干扰。
testing.T.Run 会为每个子测试创建独立的 *testing.T 实例，自带生命周期隔离、并发控制和命名空间。
常见错误现象：panic: test executed panic(nil) or runtime.Goexit —— 这往往是因为在子测试里误用了 t.Fatal 后又继续执行后续逻辑（Run 内部已处理退出，无需手动 return）。
怎么写一个干净的 Run 子测试结构
核心是把「测试输入 + 预期输出 + 执行动作」三者绑定到一个命名子测试中。名称建议用斜杠分隔层级（如 "valid_input/json_v1"），便于过滤和阅读。
- 每个
Run调用必须传入字符串名称和闭包函数，闭包参数是*testing.T - 闭包内不要用外部变量做状态传递（比如循环变量
i直接捕获），要用值拷贝或显式传参 - 子测试可以调用
t.Parallel()，但父测试不能；并行只对同级Run生效 - 子测试里调用
t.Fatal/t.Error不会影响其他子测试运行
示例：
func TestParse(t *testing.T) {
tests := []struct {
name string
input string
wantErr bool
}{
{"empty", "", true},
{"valid", `{"id": 1}`, false},
}
for _, tt := range tests {
tt := tt // 必须！防止闭包捕获循环变量
t.Run(tt.name, func(t *testing.T) {
t.Parallel() // 可选，仅当子测试无共享状态时加
if err := Parse(tt.input); (err != nil) != tt.wantErr {
t.Errorf("Parse(%q) error = %v, wantErr %v", tt.input, err, tt.wantErr)
}
})
}
}
Run 的命名和过滤实战技巧
Go 测试框架把 Run 名称作为路径段处理，支持嵌套斜杠（"HTTP/POST/timeout"），这对 API 测试特别有用。
- 运行单个子测试：
go test -run TestParse/valid（匹配所有含valid的子测试名） - 运行某一层级：
go test -run TestParse/HTTP - 名称里避免空格和特殊字符，否则 shell 解析可能出错；推荐小写字母+下划线+数字
- 如果子测试太多，可以用
t.Skip()临时跳过某几个，不影响整体结果统计
注意：-run 是正则匹配，不是精确字符串匹配。例如 -run TestParse/empty 会同时匹配 empty 和 empty_string —— 如果只想精确匹配，得写成 -run "TestParse/empty$"（加锚点）。
子测试里的资源清理和并发陷阱
子测试间默认不并发，除非显式调用 t.Parallel()。但一旦加了 Parallel，就要小心资源竞争。
- 文件操作、数据库连接、临时目录等共享资源必须各自独立（比如用
t.TempDir()） - 全局 map、计数器、sync.Once 等状态类对象，不能在并行子测试中直接共用
-
t.Cleanup()是最安全的清理方式：它在子测试结束（无论成功失败）后自动执行，且按注册逆序调用 - 不要在
Run闭包外 defer 清理逻辑——那属于父测试生命周期，不是子测试的
容易被忽略的一点：t.Parallel() 必须在子测试函数开头就调用，否则 panic；而且它只影响当前子测试与其他同级子测试的调度，并不改变执行顺序语义。
