表驱动测试应使用具名struct封装输入、预期和上下文，字段名明确（如name、input、expectederr）、类型具体，配合t.run(name, ...)提升可读性与并行性，错误比较优先用errors.is/as而非==或error()字符串比较。
用 struct 定义测试用例，别写一堆变量
表驱动测试的核心不是“多写几个 if”，而是把输入、预期、上下文打包成结构体。否则容易散落成十几个独立变量，改一个字段要翻三处。
常见错误是直接用 map[string]interface{} 或切片套切片，导致类型丢失、IDE 无法跳转、字段名拼错不报错。
- 用具名
struct，字段名明确（如input,expectedErr,expectedOutput） - 字段类型尽量具体（
error而非interface{}，string而非any） - 测试名字段建议加
name，方便t.Run(name, ...)输出可读失败信息
tests := []struct {
name string
input string
expectedLen int
expectedErr error
}{
{"empty", "", 0, nil},
{"hello", "hello", 5, nil},
{"nil", "", 0, <code>io.EOF</code>},
}
t.Run() 必须用，且名字带上下文
不用 t.Run() 的表驱动测试，失败时只显示 “test failed”，根本看不出是哪个 case 崩了。更糟的是，如果某个 case panic，后续所有 case 都被跳过。
名字不能只写序号或 "case1" —— 这类名字在 CI 日志里毫无意义。
立即学习“go语言免费学习笔记（深入）”；
- 名字应体现关键差异：输入特征、边界条件、错误路径，比如
"negative_number_returns_error" - 避免空格和特殊字符，Go 测试框架对名字没做清洗，空格可能被截断
- 如果输入太长（如 JSON 字符串），取哈希或摘要，别直接塞进名字
错误比较别用 ==，优先用 errors.Is() 或 errors.As()
很多测试崩在错误判断上，因为写了 if gotErr != tt.expectedErr。Go 的 error 是接口，两个相同内容的 error 实例地址不同，== 永远 false。
还有人用 err.Error() == "xxx"，这会漏掉包装错误（fmt.Errorf("wrap: %w", err)）和本地化错误消息。
- 预期是特定错误类型？用
errors.As(gotErr, &target) - 预期是某个底层错误？用
errors.Is(gotErr, <code>os.ErrNotExist) - 真要比较字符串内容（极少数场景），先
errors.Unwrap()到最内层再比
别在测试表里放不可序列化的值（如 func、chan、sync.Mutex）
有人想在测试 struct 里存一个闭包做“动态断言”，或者塞个 time.Now() 当基准时间——这会导致编译失败或运行时 panic，因为 struct 字面量初始化时会尝试求值。
更隐蔽的问题是：某些值（如 http.Client）虽能初始化，但会干扰并发测试（如复用连接池），让测试间产生意外依赖。
- 所有字段必须是可字面量初始化的纯数据：基本类型、指针、
error变量、struct{}等 - 需要逻辑判断？把断言逻辑提到
t.Run内部，用闭包捕获测试数据即可 - 时间敏感？统一用
time.Date(2000, 1, 1, 0, 0, 0, 0, time.UTC)这类确定值，别调time.Now()
