t.Run让测试更清晰，因其为每个子测试提供独立生命周期（计时、失败标记、日志），支持精准运行与调试，避免混杂逻辑导致定位困难。
为什么 t.Run 会让测试变清晰而不是更乱
因为单个测试函数里混着多个逻辑分支时，失败后你根本不知道是哪个 case 崩了。t.Run 不是加一层嵌套那么简单——它让每个子测试拥有独立生命周期：单独计时、独立失败标记、独立 t.Log 输出，还能在 go test -run=TestName/SubName 中精准运行某条路径。
常见错误现象：t.Fatal 在子测试里触发后，整个外层测试直接退出，其余子测试不执行；或者忘记给 t.Run 第一个参数传字符串字面量（比如用了变量），导致测试名动态变化，CI 里无法稳定识别。
- 子测试名必须是稳定字符串，避免用
fmt.Sprintf拼接（除非你确认不会影响过滤） - 所有 setup/teardown 应放在
t.Run内部，别依赖外层变量状态 - 别在子测试里调
t.Parallel()后又读写共享变量，竞态检测会报错
怎么写可维护的 subtest 结构
核心原则：每个 t.Run 对应一个「输入-预期-行为」闭环。不是按代码顺序切分，而是按业务语义分组——比如 HTTP handler 测试，按 status code 分组比按字段校验顺序分更直观。
使用场景：验证同一函数对不同输入组合的响应；测试带配置开关的功能路径；覆盖 error path + success path 的对照。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用描述性名字，如
"returns_400_when_body_is_empty"，别用"case1" - 把共用初始化逻辑抽成闭包或局部函数，但确保每次调用都产生干净状态
- 如果子测试之间有强依赖（比如要复用某个临时目录），说明它们本不该拆成 subtest，该合并或改用
TestMain
// 示例：好结构
func TestParseDuration(t *testing.T) {
tests := []struct {
name string
input string
wantErr bool
wantDur time.Duration
}{
{"empty", "", true, 0},
{"valid", "5s", false, 5 * time.Second},
}
for _, tt := range tests {
tt := tt // 防止循环变量捕获
t.Run(tt.name, func(t *testing.T) {
d, err := time.ParseDuration(tt.input)
if (err != nil) != tt.wantErr {
t.Fatalf("ParseDuration(%q) error = %v, wantErr %v", tt.input, err, tt.wantErr)
}
if !tt.wantErr && d != tt.wantDur {
t.Errorf("ParseDuration(%q) = %v, want %v", tt.input, d, tt.wantDur)
}
})
}
}subtest 和 benchmark / fuzz 怎么共存
不能。Go 的 testing.B 和 testing.F 不支持 t.Run ——B.Run 和 F.Run 是完全不同的方法签名，且语义也不同：benchmark 子项是并行压测，fuzz 子项是变异驱动，和测试的层级断言无关。
性能影响：大量 subtest 本身不拖慢执行，但每个 t.Run 调用有微小开销（创建新 *T 实例）。如果你有上千个 subtest，建议检查是否真需要全部跑，或考虑用表格驱动+条件跳过。
- 别在
go test -bench里试图调t.Run，会编译失败 - fuzz 测试中要用
f.Add/f.Fuzz，不是t.Run - 想对 subtest 做性能分析？只能单独提取出来写成独立
BenchmarkXxx函数
容易被忽略的 panic 捕获问题
子测试里 panic 不会自动转成失败，而是直接终止当前子测试并打印 stack trace——但外层测试继续跑。这会导致你以为“只崩了一个 case”，其实 panic 后的断言全被跳过了。
真正的问题在于：你没法用 recover 拦截 t.Run 内部的 panic，因为 *T 不暴露底层 goroutine 控制权。
- 唯一可靠方式是让被测代码自己处理 panic，或用
testify/assert等库的panics断言辅助 - 如果必须测 panic 场景，单独写一个子测试，用
defer+recover包住调用，并显式t.Error校验 - CI 日志里看到 “panic: …” 但测试状态是 PASS，八成是这里漏了处理
层级测试不是为了炫技，是当你改一行逻辑就要手动翻十页测试用例时，才真正体现出价值。而那个最常被删掉又最容易出问题的，永远是 tt := tt 这一行。
